Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wish that ocamlopt compile .cpp files as well as c files #5823

Closed
vicuna opened this issue Nov 14, 2012 · 6 comments
Closed

wish that ocamlopt compile .cpp files as well as c files #5823

vicuna opened this issue Nov 14, 2012 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Nov 14, 2012

Original bug ID: 5823
Reporter: daweil
Status: acknowledged (set by @damiendoligez on 2014-06-04T19:57:35Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.00.1
Category: compiler driver
Tags: patch
Has duplicate: #6798
Monitored by: @whitequark @ygrek

Bug description

I tried the following very simple patch that seems to work :

diff -ur ocaml-4.00.1/driver/main.ml ocaml-4.00.1_patched/driver/main.ml
--- ocaml-4.00.1/driver/main.ml Wed May 30 13:29:48 2012
+++ ocaml-4.00.1_patched/driver/main.ml Thu Nov  8 11:27:45 2012
@@ -52,7 +52,7 @@
     ccobjs := name :: !ccobjs
   else if Filename.check_suffix name ext_dll then
     dllibs := name :: !dllibs
-  else if Filename.check_suffix name ".c" then begin
+  else if Filename.check_suffix name ".c" or  Filename.check_suffix name ".cpp" then begin
     Compile.c_file name;
     ccobjs := (Filename.chop_suffix (Filename.basename name) ".c" ^ ext_obj)
               :: !ccobjs
diff -ur ocaml-4.00.1/driver/optmain.ml ocaml-4.00.1_patched/driver/optmain.ml
--- ocaml-4.00.1/driver/optmain.ml      Wed May 30 13:29:48 2012
+++ ocaml-4.00.1_patched/driver/optmain.ml      Thu Nov  8 11:34:20 2012
@@ -51,7 +51,7 @@
   else if Filename.check_suffix name ext_obj
        || Filename.check_suffix name ext_lib then
     ccobjs := name :: !ccobjs
-  else if Filename.check_suffix name ".c" then begin
+  else if Filename.check_suffix name ".c" or  Filename.check_suffix name ".cpp" then begin
     Optcompile.c_file name;
     ccobjs := (Filename.chop_suffix (Filename.basename name) ".c" ^ ext_obj)
               :: !ccobjs

and add the following rule for ocamlbuild:

  rule "C files  cpp -> o"
    ~insert:`top
    ~prod:x_o
    ~dep:"%.cpp"
    begin fun env _build ->
      let c = env "%.cpp" in
      let o = env x_o in
      let comp = if Tags.mem "native" (tags_of_pathname c) then !Options.ocamlopt else !Options.ocamlc in 
      let cc = Cmd(S[comp; T(tags_of_pathname c++"c"++"compile"); A"-c"; Px c]) in
      if Pathname.dirname o = Pathname.current_dir_name then cc
      else Seq[cc; mv (Pathname.basename o) o]
    end;
@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

Comment author: @damiendoligez

Your patch won't work because you failed to change the calls to "chop_suffix". Also, this would change the requirements on configure from "find a C compiler" to "find something that can indifferently compile C and C++". I'm not sure if that is a big deal or not, but it has to be considered.

@vicuna
Copy link
Author

vicuna commented Jul 9, 2013

Comment author: daweil

No, that's not a big deal, but just a nice feature if ocaml & ocamlbuild can handle both C and C++ files...

@vicuna
Copy link
Author

vicuna commented Jul 10, 2013

Comment author: @ygrek

if this is to be implemented, please consider also .cxx and .cc extensions..

@vicuna
Copy link
Author

vicuna commented Apr 21, 2015

Comment author: @whitequark

This patch is not enough because it won't link the C++ standard library. The only remotely portable way to do so is to remember whether C++ files were used during compiling and invoke g++ (or equivalent) instead of gcc (or equivalent) during linking.

Alternatively you could try detecting how the standard library is named (nontrivial; current OS X has two) and putting it in cma's autolink flags, but I'm not sure if that's a simpler choice.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 15, 2020
@whitequark
Copy link
Member

Can be closed as duplicate, since the attached patch has significant flaws.

@nojb nojb closed this as completed May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants