While this is easy to do with eg Perl I am not sure how to handle this
with just a Makefile. The straightforward approach with handling
<module>.done files does not work. And that is one of the reasons why
I
don't think that (GNU) makefiles are a good solution for any problem.
Most
of us are used to program object oriented/imperative. Makefiles
require
a
declarative approach. Maybe the use of Perl is not such a bad idea.
Maybe
it would be better to reimplement build.pl with a lot fewer options
and
with better readable code.
I agree that makefiles are nowhere near a good solution to many of
these
problems, but its like windows, I dont like it, but everybody uses it.
We could easily write a new build.pl, that also took care of the local
makefiles, but our build system would not be in the mainstream, and e.g.
the distros would not like to integrate AOO.
I have over the last years followed research in building systems, and
there
are (sadly enough) nobody that tries a real object oriented aproach.
Also
if you look at packages like visual studio, QT, eclipse they all use the
principle of makefiles with declarative approach.
So my simple question is, do we want to approach the main road
(makefiles
for unix, visual studio for windows/mac) or do we want to have better
but
non standard system.
Good analysis. Maybe I should answer with Faust: "Zwei Seelen wohnen,
ach! in meiner Brust" (two souls alas! are dwelling in my breast). The
pragmatist says to use the make. It is good enough for others, it is
good
enough for use.
On the other hand, when I start a new project I usually start with the
question of what are the best tools for the problem at hand. And make
does
not seem to be the first or the best answer. Look at our dmake or gbuild
system. Both don't use make in a standard way. gmake even defines its
own
language, object oriented and imperative, on top of the GNU make macros.
That is, for me, an act of desperation.
I have made experiments with an alternative approach, a domain specific
language somewhat similar to Java. I personally like this approach
because
a) it uses the paradigm that I already use when writing C++ code. That
means that I can apply my existing knowledge to the build process and
that
I don't have to remember all the tricks and pitfalls of makefiles.
b) as expected it was much easier to handle file dependencies and
parallel
processing of build jobs in Java than adding object orientation and
imperative control flow to makefiles.
If I had the time and if I would be the one working on it then I would
prefer an non-Makefile approach. But maybe I am just suffering too much
from one of the 'three great virtues of a programmer': hubris.
You are the one who leads the build project changes, so you have to
decide
which approach to use. I am not trying to make your life harder (than
necessary), I am only trying to point out some of the pitfalls that I
have
encountered in the past. And to prevent you from removing features that
I
use :-)
rgds
jan I.
Ps. its always refreshing to discuss with you, you often have an
alternative approach, which is not just a dream but doable.
Thanks. That makes two of us.
Have a nice weekend,
Andre
-Andre
--prepare
Also one option that is important for our every day work. Use
case:
You make changes in <module> and are not sure if these changes are
compatible/incompatible. To be on the safe side you discard the
output
of
all depending modules. To save time you keep the output of all other
modules.
Often used together with '--from' like 'make --prepare --from
svx' to
prepare a build after making changes in svx.
Documentation changed, funny thing is that svx does not clear
correctly
on
my ubuntu build.
--since <module>
A variant of '--from'. The only difference is that <module>
itself
is
not built.
If your proposed approach is similar to what my script produces
then
it
is not too difficult to support --from/--since. I made some
experiments
in
this direction but was to lazy to finish them.
My approach is very similar, but I failed to see how --since is
supported.
And question is if its real important.
--job
--pre_job
--post_job
These are sometimes handy to run a non-standard command for all
modules.
I have added them, they are by the way a good example why we need a
discussion I have never used them.
However maybe the real discussion is "do we want to replace build and
have
a main/Makefile instead?"
- I have not used the rest of the unsupported options and would not
miss
them. Others may have other sets of options that are important to
them.
Some general remarks:
- Why keep one makefile per module? Why not put all the inter-module
dependencies into one file (like my script does)?
Ups, I did not explain that correctly, I propose 1 Makefile
"main/Makefile"
with all inter-module and 1 Makefile "<module>/Makefile" that today
just
will call the old makefiles as described in prj/build.lst
- Why not use the oportunity to move (a part of) the build environment
out
of the way to, say, build/ ?
You have guessed my next step.
- How are dependencies between modules handled (just the manual
dependencies from prj/build.lst or also the file dependencies
introduced
by
gmake).
See doc. on --from. Its done with <module>.done files
- How is the output of the individual calls to dmake or GNU make
handled/made accessible. Ie. if there is a build error, how can I
look
up
the corresponding build output?
see doc. script make_log
- Are the gmake makefiles included (run in the same process) or is
GNU
make started for them it its own process?
For a start they would be called (own process), but its something
where
I
have no strong opinions.
Please (just to be sure), this proposal has nothing to do with the
students
work, its simply because I saw a positive discussion on removing
build.pl
,
and spent a couple of hours looking at it. If there is a preference
not
to
remove build.pl I will simply forget it.
rgds
jan I.
Regards,
Andre
It has been roughly tested it, thanks to a clever utility from
andre.
As discussed build.pl contains a lot of options, which need to be
considered in a makefile.
My suggestion is on
http://wiki.openoffice.org/******wiki/Build_System_Analysis:**<
http://wiki.openoffice.org/****wiki/Build_System_Analysis:**>
**<http://wiki.openoffice.org/****wiki/Build_System_Analysis:**<
http://wiki.openoffice.org/**wiki/Build_System_Analysis:**>
build.pl_versus_makefile<http:****//wiki.openoffice.org/wiki/****<
http://wiki.openoffice.org/wiki/**>
Build_System_Analysis:build.****pl_versus_makefile<http://**
wiki.openoffice.org/wiki/**Build_System_Analysis:build.**
pl_versus_makefile<
http://wiki.openoffice.org/wiki/Build_System_Analysis:build.pl_versus_makefile
Please feel free to edit/comment on the page. I have reduced to
options
a
lot, and some of them might be in use.
thanks in advance for your comments.
------------------------------******--------------------------**
--**
--**---------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.****a**pache.org<
http://apache.org**>
<dev-unsubscribe@**openoffice.**apache.org<
http://openoffice.apache.org>
<dev-unsubscribe@**openoffice.apache.org<
dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org
------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<
http://apache.org>
<dev-unsubscribe@**openoffice.apache.org<
dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org
------------------------------**------------------------------**---------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
dev-unsubscr...@openoffice.apache.org>
For additional commands, e-mail: dev-h...@openoffice.apache.org
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
