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
add environment variables to control compiler options #5723
Comments
Comment author: @alainfrisch I fully support the request. My personal preference would be generic environment variables (one per tool: OCAMLCFLAGS, OCAMLOPTFLAGS, OCAMLDEPFLAGS, plus maybe a generic one OCAMLFLAGS), split into arguments and analyzed with the standard command-line parser (before real command-line arguments). This requires less implementation and documentation work than creating a new convention, less things to know for the user, and it is more future proof (if a new command-line option is supported, it will be automatically available). |
Comment author: meyer Attached patch that does that. Documentation needs to be updated too. If there are no objections I will commit it this week. |
Comment author: @lefessan Sorry, but I have a few objections to your patch: 1/ you implemented only OCAMLFLAGS, OCAMLCFLAGS and OCAMLOPTFLAGS, but what was discussed was one variable per tool. There should at least be OCAMLDEPFLAGS too, and maybe other ones (OCAMLMKLIB ? OCAMLMKTOP ?). 2/ Also, the fact that OCAMLFLAGS is "generic", means that there is no specific options for the ocaml toplevel. 3/ the use of Misc.rev_split_words means that there is no way to escape spaces in paths in these variables 4/ the fact that most ocaml options are only available in one way (i.e. there is -g, but not -not-g) means that there is no way to unset options that are set in these variables. It would be worth thinking about this problem too. |
Comment author: meyer
That's ok, I was expecting a thorough review, thanks!
OCAMLDEPFLAGS is implemented, but due to simplifying dependency management, I decided to just specify the string.
Yes, we need to discusss it further. Would you like to have a generic flag or OCAMLFLAGS for the toplevel?
Good catch! What would you propose then?
OK, I'll raise a Mantis issue how we can implement un-setting, but I think it goes beyond this issue for time being - as it's not possible to do even disabling them even with concatenation of these in standard build tools. |
Comment author: @gasche A version of this for the compilers only (ocamlc and ocamlopt) was finally implemented in trunk and version/4.01 by Fabrice. |
Original bug ID: 5723
Reporter: @lefessan
Assigned to: meyer
Status: closed (set by @xavierleroy on 2015-12-11T18:21:14Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 4.01.0+dev
Category: ~DO NOT USE (was: OCaml general)
Related to: #5699 #5721
Monitored by: tgazagna mehdi Camarade_Tux @jmeber @hcarty @Chris00 @alainfrisch
Bug description
Sometimes, it can be useful to be able to change the behavior of the compiler without changing the build system files. For example, you might want to build a debug version (-g) or a profile version (-p), but you don't want to spend time changing the Makefile/ocamlbuild/_oasis/etc. (and you don't want to risk to commit them in the SVN/git/etc.), so you would just want to set an environment variable, and have the compiler set the option from th(is/ese) environment variable(s).
Now, the discussion is, whether there should be one (OCAMLFLAGS), one per tool (OCAMLCFLAGS, etc.) or one per option. My personal taste is one per option (for the ones that make sense) or one that is a bitfield (OCAMLCOMPPARAM, à la OCAMLRUNPARAM).
Additional information
(I opened this report because this discussion is polluting other bug reports)
File attachments
The text was updated successfully, but these errors were encountered: