Re: Auto-tools & Win32 & Borland C++ Builder

[Martin Hollmichel]

Hi all,

I think the great misunderstanding is that the autotools are 
not targeting real multiplatform development, but Unix centric
distribution of (GNU) OpenSource Software.

To do real multiplatform, multitools development the autotools 
are difficult to use (IHMO). Try to introduce other compilers then 
(GNU) C, (GNU) C++ Compilers (idl – Compiler, Javac, Resource Compiler, 
whatever compilers, other dependency generators and you 
going mad (in my experience).

I was often ask why we (I'm responsible for OpenOffice.org build
environment on Unix, Windows and Mac platforms) don't use autotools,
I say: it's right now not possible and didn't make 
much sense for really big and multiplatform 
development). I would like to, but I can't, sorry.

A few more examples:
* changing a autotool file, then waiting for configure to write 1200 
makefiles.
* Mixing up debug and non debug build, do both causes double compile 
time, double diskspace and x-time more RAM for the debugger. Imagine to 
need 10 GB for Openoffice debug build and more than 2GB RAM to start the 
result in a debugger.
* try to build a four year old glibc on a two year old Linux system or 
vice versa. You have to begin to hack a configure.in.
* using 30 year old preprocessor technology is not the most comfortable 
way of doing Software Configuration Management (SCM) and script 
development.

Maybe I'm wrong but is there better bibliography than the info files and 
GNU Autoconf, Automake and Libtool book by Vaughan, Elliston, Tromey and 
Taylor?

Don't get me wrong, I think the autotools a great tools and I don't want 
to miss them, but for doing active software development it's not the 
optimal tool.

Anybody who like to give hints to use autotools for OpenOffice.org ?

Flame me,
        Martin Hollmichel

> Another scheme is of course the usage of the C++Builder
> as a front-end, and use its project-files to generate
> a makefile(.am/.in) that can make it build in environments
> that don't have a borland compiler. Again, you'd have to
> change away anything that is non-portable across compiler
> sets, so one could start to use gcc's c++ anway, which
> again does not need bcc support in the original setup. So
> I guess, approaching autotools enthusiasts, it may come
> out to the question why you're using borland compiler-chain
> anyway as portability is best achieved with the gcc itself.
> Again, partly a pedagogical endavour (if not flames) that
> should be limited to one mailing-list. Possibly libtool.