Re: Perhaps stupid request
> I must admit, I fully agree with Bernhard. OpenOffice ibuild system is ugly,
> ugly, ugly, and once more ugly.
This argument doesn't convince me. arguments don't get better by repeating.
> Hope I'll explain managers at work, how build
> system is important for developer, that it is more important then these silly
> internationalization fixes and features, that it will give more attention to
> our company throughout the world, etc, etc, <usual trash that we often say to
> our managers follows>. In this case I'll have more time to work on build
I fully agree, the build system is very important to developer and this is the reason
for not choosing autotools, autotools is a code destribution system but not a build
system. Yes it does building, but not for developing code but for transfering source
code into a systems structure. I understand that this is perfectly that what is your
interest, but that was never the goal of the OpenOffice.org build system.
>From my standpoint there are two alternatives:
1. expanding autotools to a build system.
2. expand OOo build system to a code destribution system.
I don't see that approach #2 would be accepted by the community
* because for little project autotools seem to be a reasonable build system
* why switch to another system if there is a working system
=> in other words: I don't see the demand in OpenSource for a multiplatform
ehancing the autotools seems the more feasable way to me but it also have IHMO some
* two macro languages are used:
* the m4 language
* the make syntax
developing code im a macro language get more difficult if the size of the project
grows (It doesn't scale).
* shell programing is needed. I think everybody who has developed sh scripts on
different platform will agree, that it gets difficult if there are coming non
GNU platforms like Solaris, AIX , HP/UX into play. all the tools differs in
implementation and version ( just do a "man sh", "man test" ) on the different
Unix flavors and you see that you have to test autotools script on every platform.
this makes the developing of a new macro in autotools a quite time consuming process.
so there are at least three different languages involved at autotools and they are
quite ancient. I know thousand of people which are using autotools but only a few
which are able to adopt their build system to autotools and only a very few which
are able to develop new features in autotools.
to make it short: I dont't see anybody available right now, who is able and get the
time to do ehancements for more features in autotools.
> My idea differs from Bernahrd's a little. I know that it is easy for Suners to
> keep it in one big source tree. I'm thinking about making alternative build
> system that does everything that current does (solver, etc.), but based on GNU
> Make and autotools. It will be politically correct, because build systems won't
> interfere with each other, and my will be more flexible.
If we come to a consens that we each accept the weaks of both approaches
discussion will get easier.
What is the definition of a political correct buildsystem:
* has it to be autotools
* or has it just to be (L)GPL.
I think a comprimise would be that each build system can call each other and has to
> > ok, traveling with dependencies has it's own tool, build.pl to avoid the
> > usual problems with recursive makefiles.
> dependancies should be dynamic. dixi.
I don't understand this. directory dependencies are coded staticly into makefiles and
not generated dynamicly in autotools/other makefiles.