|Anonymous | Login | Signup for a new account||2014-03-10 04:51 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005723||OCaml||OCaml general||public||2012-08-08 13:03||2013-07-28 23:24|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version||4.01.0+dev|
|Summary||0005723: add environment variables to control compiler options|
|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)|
|Tags||No tags attached.|
|Attached Files||0001-PR-5723-Add-environment-variables-to-control-compile.patch [^] (10,021 bytes) 2012-11-19 06:49 [Show Content]|
|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).|
Attached patch that does that.
Documentation needs to be updated too. If there are no objections I will commit it this week.
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.
> Sorry, but I have a few objections to your patch:
That's ok, I was expecting a thorough review, thanks!
> 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 ?).
OCAMLDEPFLAGS is implemented, but due to simplifying dependency management, I decided to just specify the string.
I'll implement the logic for the rest of the tools too.
> 2/ Also, the fact that OCAMLFLAGS is "generic", means that there is no specific options for the ocaml toplevel.
Yes, we need to discusss it further. Would you like to have a generic flag or OCAMLFLAGS for the toplevel?
I propose OCAMLTOPFLAGS as the one for the toplevel.
> 3/ the use of Misc.rev_split_words means that there is no way to escape spaces in paths in these variables
Good catch! What would you propose then?
If there is no existing solution I'll implement own function in Misc.
> 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.
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.
|A version of this for the compilers only (ocamlc and ocamlopt) was finally implemented in trunk and version/4.01 by Fabrice.|
|2012-08-08 13:03||lefessan||New Issue|
|2012-08-08 13:03||lefessan||Relationship added||related to 0005721|
|2012-08-08 13:04||lefessan||Relationship added||parent of 0005699|
|2012-08-08 13:04||lefessan||Relationship deleted||parent of 0005699|
|2012-08-08 13:05||lefessan||Relationship added||related to 0005699|
|2012-08-28 09:47||frisch||Note Added: 0007990|
|2012-08-31 20:34||meyer||Assigned To||=> meyer|
|2012-08-31 20:34||meyer||Status||new => assigned|
|2012-11-19 06:49||meyer||File Added: 0001-PR-5723-Add-environment-variables-to-control-compile.patch|
|2012-11-19 06:51||meyer||Note Added: 0008530|
|2012-11-19 10:02||lefessan||Note Added: 0008531|
|2012-11-19 14:39||meyer||Note Added: 0008534|
|2013-07-28 23:23||gasche||Note Added: 0009951|
|2013-07-28 23:23||gasche||Status||assigned => resolved|
|2013-07-28 23:23||gasche||Fixed in Version||=> 4.01.0+dev|
|2013-07-28 23:23||gasche||Resolution||open => fixed|
|Copyright © 2000 - 2011 MantisBT Group|