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
Enable the "-use-ocamlfind" option by default #5547
Comments
Comment author: @gasche I have discussed this with xclerc and he agrees on principle -- but we should try to get feedback from the original implementors, npouillard and Romain Bardoux, before making changes. I'm directly marking the issue "acknowledged" to avoid burdening the bug triagers. (Of course, feedback is still welcome.) |
Comment author: @dbuenzli Just two things.
|
Comment author: william For your information, I support this feature.
This is related to bug #5406 |
Comment author: meyer I agree with ubiquity of ocamlfind we should support it. So based on your observations here are the remarks:
|
Comment author: william Hello,
based on your remarks, two would be modified :
And finally, the other possibility is do the exactly the opposite :
Regards |
Comment author: meyer Agreed. We'll mark the -use-ocamlfind switch as deprecated in this case. |
Comment author: william Related to this, With this, even when ocamlfind is not activated (in 3.12.1, with "use-ocamlfind" not used), ocamlbuild manages to compile some packages calling ocamlfind! (though it fails in the end). |
Comment author: meyer Indeed, this support is a bit outdated, I believe intentions were good, but it's confusing. I'll look into this area and consider depreceation or removal, with a reservation that some parts might be still useful. |
Comment author: Camarade_Tux I was in favor of such a change at first but I see several issues now. How to build the compiler (when ocamlfind isn't available)? Automatically fallback or explicitely disable ocamlfind would both work but that's still something to do If ocamlbuild which is part of the standard distribution starts relying on ocamlfind, wouldn't it make sense to have ocamlfind be part of the standard distribution too? (As far as I'm concerned, I'd prefer to have ocaml{doc,debug,build,...} outside of the core distribution and using ocamlfind; mostly because that ease updates and building of a cross-compiler). This would conflict with oasis (or at least be made useless by oasis). The support has been lagging so far with issues with threads iirc. I don't believe this would be better in the future: if there's something new in ocamlfind, it would need an update to the compiler and that's simply too much (did I mention I was in favor of splitting components?). That said, this support is used, including by me, especially for short-lived codes, but that's when I don't want to take time to setup an actual build environment. The way I see it:
All of these require work to be done before making ocamlbuild try to default to using ocamlfind. So as of today, I believe -use-ocamlfind shouldn't be the default and should be deprecated and removed in a future release. |
Comment author: @gasche
We would have an option -no-use-ocamlfind. Integrating that into the
I am not aware of any plan to integrate more things in the standard
I don't understand this point; could you elaborate? Oasis has
I don't know what you are referring to. Could you elaborate? Are you
What do you use otherwise?
What do you recommend using instead? The ocamlfind plugin that is |
Comment author: meyer Fix on trunk, revision 13938. |
Comment author: meyer This will break OASIS and platform builds, so we have to think to up-stream the fixes before beta, but maybe at most after RC. |
Comment author: @dbuenzli Note that other players in the build area (obuild and ocp-build) provide built-in support for reading META files. That could be an alternative, less breaking, path. |
Comment author: @hcarty Will this make it into 4.01? |
Comment author: meyer dbuenzli: might be worth to try. I will experiment with that over the weekend. hcarty: I think it will, if we are confident that rest of the infrastructure will be fixed. |
Comment author: meyer dbuenzli, I raised #6094, specifically for this work (parsing META files), as I found it a good feature. |
Comment author: @gasche With the fix only in trunk and not in the version/4.01 branch, this will not (by default) get into 4.01. I think that's the better choice, because this change may have far-raising consequences and the timeframe to fix things outside the distribution is too short. Really, at this point in the release cycle we shouldn't break outside stuff. |
Comment author: meyer I'm fine with shifting it to the next release, however I'd like people to test it with the platform now. If somebody can see if trunk still works with OPAM it would be great (I can do it myself, but currently my desktop machine is broken) |
Comment author: @avsm
I've just recompiled trunk and installed a few packages, and all seems normal enough. I'll kick off a bulk build later when some machines free up from 4.01.0dev tests. |
Comment author: meyer Thank you! Let me know how it goes, did you need to use -no-ocamlfind flag? |
Comment author: @avsm I did not add any extra flags to any packages. I'll update this ticket if any regressions do show up. |
Comment author: meyer Interesting, I was expecting problems. Note that ocamlfind command will be always used for invoking the compiler, but maybe oasis does that by default too. |
Comment author: jpdeplaix Related to: #20 Do we really want that ? |
Comment author: @gasche We have to make a choice as to whether we keep the statu quo, which is to enable -use-ocamlfind by default, or revert the change and keep the default behavior (not using ocamlfind) of 4.01. I'm "re-opening" this ticket as a central place for this discussion. The argument in favor of changing the default is the following: all "small users" of ocamlbuild also use ocamlfind and always enable -use-ocamlfind, so enabling it by default is much more convenient. It also allows to document and discuss usage of ocamlbuild with ocamlfind integration directly, in a more user-friendly way. The -no-ocamlfind option would be reserved to expert/"large" users that have reasons to avoid ocamlfind (eg. Mirage). The argument against are of various nature:
A last remark is that this makes the default parameter for ocamlbuild (which is included in the OCaml distribution, at least for 4.02) depend on an external OCaml tool, which is "odd". I don't think this is problematic: arguably Stream depends on a camlp4 syntax extension for most sane uses, and generally it makes sense to make in-distribution tools interact better with the outside ecosystem when possible (of course a "bare" mode should be available, which it is). External factors to consider are:
A possibility (suggested by Thomas) is to have ocamlbuild detect whether ocamlfind is available, and enable -use-ocamlfind by default only if it is -- curently it fails if ocamlfind is absent and -no-ocamlfind is not given. While nice on paper, I'm worried that this may create further problems down the line (harder to detect because of a moving default behavior). |
Comment author: @avsm I believe that changing the default behaviour while ocamlbuild is distributed as part of OCaml would cause more problems than it solves. It would be far simpler to proceed with the discussion in #6402 to split ocamlbuild out in 4.03, and leave the resulting package free to depend on ocamlfind once it is external to the core distribution. Also: how are packages supposed to use this across OCaml versions? Since |
Comment author: @gasche My worry with the "let the splitters deal with the problem" argument is that it only delays the problem further. If the split-out package uses -use-ocamlfind by default, you will have the exact same backward-compatibility problem with -no-ocamlfind not being supporter on older versions. (Delaying the question from 4.01 to 4.02 didn't help, why would the move from 4.02 to 4.03 bring any clarity?) I think we should make a decision now: |
Comment author: @gasche (Not sure why the status changes so much, it's not intentional; sorry for the noise) |
Comment author: @avsm Just add the -no-ocamlfind flag for this 4.02 release, and then the 4.03 upgrade path (spit or not) will be much easier. |
Comment author: ybarnoy Maybe it's worth backporting this change to previous ocaml versions? |
Comment author: @gasche Dear all, Given the lack of apparent interest in the issue, my current plan is to heed Anil's advice and revert the change for 4.02. I'm not really satisfied with it, but time is running short and at some point you need to let go. I plan to implement that shortly (before the week-end) so that it can be part of the next beta release, whenever that happens. |
Comment author: jpdeplaix When you say « implement », do you suggest that there is more to do than just #60 ? |
Comment author: @gasche -no-ocamlfind is now the default again in 4.02 and trunk. |
Comment author: @damiendoligez ocamlbuild is now a separate tool that lives on GitHub. |
Original bug ID: 5547
Reporter: @gasche
Status: resolved (set by @damiendoligez on 2017-03-03T14:33:48Z)
Resolution: suspended
Priority: normal
Severity: feature
Fixed in version: 4.02.0+dev
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Related to: #5406 #6118
Monitored by: @whitequark @gasche mehdi @diml @ygrek @glondu @hcarty @dbuenzli @Chris00
Bug description
Ocamlfind is everywhere these days and I frequently forget to add the "-use-ocamlfind" knob to enable the nifty "package(foo)" syntax. I'm not sure why it was enabled by default (maybe there was a conflict in semantics somewhere) but I would like it if it became the standard (with why not an opt-out option "-no-ocamlfind").
It would be useful in particular when used with Oasis, which currently has the limitation that we can't pass command-line parameters to the ocamlbuild invocation directly. That's a bug that will eventually be fixed, but there may be similar situations present in other tools.
The text was updated successfully, but these errors were encountered: