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

add environment variables to control compiler options #5723

Closed
vicuna opened this issue Aug 8, 2012 · 5 comments
Closed

add environment variables to control compiler options #5723

vicuna opened this issue Aug 8, 2012 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Aug 8, 2012

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

@vicuna
Copy link
Author

vicuna commented Aug 28, 2012

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).

@vicuna
Copy link
Author

vicuna commented Nov 19, 2012

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.

@vicuna
Copy link
Author

vicuna commented Nov 19, 2012

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.

@vicuna
Copy link
Author

vicuna commented Nov 19, 2012

Comment author: meyer

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.

@vicuna
Copy link
Author

vicuna commented Jul 28, 2013

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.

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

1 participant