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

[Guido Draheim]

Martin Hollmichel wrote:
> 
> 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.

well, they are not restricted to the *but* IMHO. They are
just not 100% ready-made however it can do quite some
multiplatform development even now - and indeed quite more 
than most (all?) other tools around.

> 
> 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.

I support these arguments too. Probably others share them.

> 
> 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?

ask the latter four ;-)

> 
> 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.

alternatives? I mean free, documented, mature, easy alternatives to be seen?

> 
> Anybody who like to give hints to use autotools for OpenOffice.org ?
> 
> Flame me,
>         Martin Hollmichel

No way to do flames, you have spoken, and you know what
your are talking about. PAMHO. Well, it's just an
imperfect world, and things are left to be done and
discussed, may be just not on all autotools-groups. IMO,
the strongest argument goes about automake and the
interconnections in ac_output/subdirs-scheme. (doing
the reply to automake-list now)

Personally, the restriction of one Makefile.am for
every(!!) subdirectory has been given me quite a headache
in large projects too. At one point, I did start to
break up the makefile-system, subdirectories did contain
makefiles with the generic rules and they did include
a configured-makefile-snippet from somewhere near the
configure-script, somewhat like overriding just makevars.
reconfiguring ist much faster, however dependencies were
not detected easily (still a subdirs-scheme). Another
approach had been to use one makefile for multiple
subdirs, possible a whole tree. automake however rejects
any source/target living in a subdir - sometimes I had
force-feeding it through a ac_subst that listed the
source-files. IMO, automake is already quite a huge
tool in size, it's not that easy to get extended to
other compile-rules, and easily gets offended by
source/make-trees that are otherwise easy to handle
with plain autoconf-makefiles. One does just not get
the nice rule-definitions automatically copied by
automake.

Anyway, Axel/Michel, using autoconf and libtool is often
almost easy to get working inside the common older setups, 
however using automake in the tasks, well, it's probably 
not best suited, just as you stated, on the other hand, 
looking at the knowledge built into automake, then
I doubt we can see an automake-replacement soon. Who's
going to write it? There are some projects, e.g. about
genericmakefiles, but they have often other problems, 
lack a bit of development and the integration with
libtool developments. A search at http://freshmeat.net
with "makesfiles" revealed about ten relevant projects,
e.g. prototypemakefiles, troll's tmake or rse's smake.

cheers, guido
                  http://savannah.gnu.org/projects/ac-archive

> 
> > 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.

-- guido                         Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@  d(+-) s+a- h.r(*@)>+++ y++ 5++X-