Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005723OCamlOCaml generalpublic2012-08-08 13:032013-07-28 23:24
Reporterlefessan 
Assigned Tomeyer 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.01.0+dev 
Summary0005723: add environment variables to control compiler options
DescriptionSometimes, 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)
TagsNo tags attached.
Attached Filespatch file icon 0001-PR-5723-Add-environment-variables-to-control-compile.patch [^] (10,021 bytes) 2012-11-19 06:49 [Show Content]

- Relationships
related to 0005721resolvedlefessan patch to use frame pointer to profile code with Linux perf tools 
related to 0005699confirmed It would be nice to be able to set up OCAMLINIT root directory 

-  Notes
(0007990)
frisch (developer)
2012-08-28 09:47

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).
(0008530)
meyer (developer)
2012-11-19 06:51

Attached patch that does that.

Documentation needs to be updated too. If there are no objections I will commit it this week.
(0008531)
lefessan (developer)
2012-11-19 10:02

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.
(0008534)
meyer (developer)
2012-11-19 14:39

> 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.
(0009951)
gasche (developer)
2013-07-28 23:23

A version of this for the compilers only (ocamlc and ocamlopt) was finally implemented in trunk and version/4.01 by Fabrice.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker