Dear Wolfgang,
thank you for your reply and sorry for the delay.
I'm not sure how this could work. Currently the code for "include"
looks
like this:
(1) [] include then
(2) {BatchCompiler enqueue(pushSwitches())}
(3) {BatchCompiler enqueue(setSwitch(feedtoemulator true))}
(4) {BatchCompiler enqueue(feedFile(X return))}
(5) {BatchCompiler enqueue(popSwitches())}
As far as I understand, to make your idea work line 2 and 5 must be
removed/changed and the value of "BatchCompiler" must be added to its
own environment such that the code in FILE can access the compiler
engine.
Sounds a bit like a hack, but maybe this idea is worth a try.
I understand you are suggesting we can basically integrate these
lines from mozart/share/lib/ozbatch/Compile.oz into mozart-stdlib/
ozmake/ExecutorFast.oz -- and then hand the file given at the --
include option (here variable X) somehow through to these inserted
lines in mozart-stdlib/ozmake/ExecutorFast.oz.
The two lines you 2 and 5 you mention seem to exactly prevent that
someone can set any compiler switches in an include file (i.e. that
these switches only have an effect within the file itself). So,
leaving these lines out when we integrate an --include option for
ozmake then probably allows to shoot in ones own foot. For example,
mozart-stdlib/ozmake/ExecutorFast.oz sets a number of compiler
switches, and with our include one could then unset these. However,
we could document all these set switches in the documentation of a
new ozmake --include option and warn the user not to change them...
An additional complication is, that the effect of the ozmake option --
include would be different to the effect of the ozc --include which
again needs documentation. Also, when using the ozmake --slow option,
our --include option would not have the desired effect because of the
lines you pointed to. So, we would make the two options --slow and --
include exclusive and raise an error if both are given.
Nevertheless, that seems be a strait forward way to get arbitrary
compiler options supported by ozmake. So, I am in favour even if it
is a bit hackerish.
What do you think? Has anybody a better idea?
Best
Torsten
On Sep 12, 2007, at 6:44 PM, Wolfgang Meyer wrote:
Torsten, Raphael,
thank you for the feedback.
My first idea was indeed to implement generic compiler options for
ozmake.
But there is a problem: ozmake calls the compiler in two different
ways.
By default, it uses the compiler API directly. Only with option "--
slow"
it actually calls the ozc binary. It's easy to propagate generic
options
to the compiler in the "slow" mode.
But to make it work with the "fast" mode, much of the code in
share/lib/ozbatch/Compile.oz would have to be duplicated in ozmake
(which feels like the wrong thing to do).
The cleanest solution is to integrate the functionality of Compile.oz
into the Compiler functor or to wrap it into a new functor which could
then be used by ozmake and ozc.
Alternatively, ozmake might automatically switch to the "slow" mode if
compiler options are specified. But the mode is called "slow" for a
reason.
TA> here is another idea: if ozmake would at least support the
compiler
option --include=FILE,
TA> then any compiler switch etc. can be set in FILE. The
implementation
should be relatively
TA> easy by following Wolfgang's example.
I'm not sure how this could work. Currently the code for "include"
looks
like this:
(1) [] include then
(2) {BatchCompiler enqueue(pushSwitches())}
(3) {BatchCompiler enqueue(setSwitch(feedtoemulator true))}
(4) {BatchCompiler enqueue(feedFile(X return))}
(5) {BatchCompiler enqueue(popSwitches())}
As far as I understand, to make your idea work line 2 and 5 must be
removed/changed and the value of "BatchCompiler" must be added to its
own environment such that the code in FILE can access the compiler
engine.
Sounds a bit like a hack, but maybe this idea is worth a try.
Wolfgang
Torsten Anders wrote:
Dear all,
here is another idea: if ozmake would at least support the compiler
option --include=FILE, then any compiler switch etc. can be set in
FILE. The implementation should be relatively easy by following
Wolfgang's example.
Any comments?
Best
Torsten
On Sep 12, 2007, at 7:41 AM, Raphael Collet wrote:
Dear Torsten,
For the sake of syntax, I would suggest to use "--compiler-" as a
prefix
to compiler options, so you could write things like
--compiler-warnshadow
--compiler-environment=MODULES
A generic way to specify compiler options sounds like a must-have
to me.
Cheers,
raph
Torsten Anders wrote:
Dear Wolfgang,
thank you very much for this.
There are other compiler options not supported by ozmake either
(e.g.,
all the warning options like --warnshadow). Could we perhaps add
support
for arbitrary compiler options in a generic way? For example, we
could
have an option --compileroptionsfile=PATH, where the text file
at PATH
contains arbitrary compiler options which are all hand to the
compiler
by ozmake. Of course, the users are responsible for what they are
doing.
I thought a while about an option --compileroption=OPTION, where
OPTION
is any compiler option and the option --compileroption could occur
multiple times. However, I couldn't come up with a suitable
format this
late.. Easy cases would be boolean options like
--compileroption=warnshadow
However, I don't know how to handle compiler options which expect a
list
of values...
--compileroption=environment=MODULES
BTW: any chance such changes to ozmake will make it into the main
repository?
Best
Torsten
____________________________________________________________________
_____________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_____________________________________________________________________
____________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
______________________________________________________________________
___________
mozart-users mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Torsten Anders
Interdisciplinary Centre for Computer Music Research
University of Plymouth
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
