Re[2]: [lmi] autotools versus makefiles

[Vadim Zeitlin]

On Sat, 11 Feb 2006 07:32:42 +0000 Greg Chicares <address@hidden> wrote:

... a lot of things about autoconf ...

 First of all, let me say that I've noted your conclusion at the end of
this mail and won't discuss it again, so all the rest of this message has
mostly academic interest. But I still wanted to write it because you're not
always fair to autoconf. Please feel free to skip this message unless
you're curious.


GC> > GC> How would autotools make this easier? I find a thread starting here
GC> > GC>   http://sources.redhat.com/ml/automake/2001-05/msg00359.html
GC> > GC> that seems to suggest that it's difficult to use automake with a 
compiler
GC> > GC> other than gcc.
GC> > 
GC> >  The reply in this thread makes it quite clear that the goal of autoconf 
is
GC> > to support all compiler but that, unfortunately, sometimes some GNUisms
GC> > slip in.
GC> 
GC> The incompatibilities are more severe than you expected.

 Maybe so. But they're definitely not insurmountable, in the worst cast
it's quite trivial to write a wrapper script around the native compiler
command which accepts standard Unix compiler options (which autoconf indeed
expects), like the existing wrapper around MSVC cl.exe does it. In any
case, it's definitely unfair to expect it to work with these compilers out
of the box while I never tested it with them.

GC> Let's try using autotools with MSYS to build gnu 'hello'

 This is a really bad example. As you're perfectly aware, GNU hello is not
your typical hello world program -- in fact, it's exactly the contrary.
I.e. it's not short and simple but rather tries to use as many features of
real programs as possible. It's also completely Unix-centric, and this is
why it uses NLS and pwd.h. Of course, no amount of autoconf can help if you
use the features simply not available on one of the platforms!

GC> As with boost, above

 boost doesn't use autoconf, of course, so I don't know what does it do in
this discussion?

GC> The problem I'm interested in here isn't a problem that autoconf solves.
GC> I don't want lmi used with a system that lacks, say, snprintf(), because
GC> of the security risks of sprintf(). If a system doesn't have snprintf(),
GC> then I don't mind saying: find a aystem-specific workaround that passes
GC> the unit tests,

 This is exactly the autoconf approach. If the function is not present,
you're supposed to use your own replacement for it. This is what wx does in
many cases, we just didn't have to do it in lmi because, well, all
functions are present. And if they were not, configure would exit with
fatal error, just as you say:

GC> or don't use that system at all.


GC> I'm interested in using wx-config to make the lmi makefiles clearer
GC> and easier to maintain.

 This can be done with GNU make, of course. The only difference is that
with autoconf you get it for free as wxwin.m4 provides a tested, debugged
and commonly used macro for wx-config detection.

GC> >  It certainly can. What makefile can't do is to test whether wx-config
GC> > exists and is correct (e.g. doesn't correspond to Unicode build of wx 
which
GC> > is not suitable for lmi). Of course you'd still get an error sooner or
GC> > later but it risks to be much less clear.
GC> 
GC> I don't understand. I can test a file's existence with [ -e filename ],
GC> but of course you know that already. If I'm not sure where it resides,
GC> I could use 'find', though that risks finding a variety of different
GC> builds.

 You can test the file existence if you know where it is which is not
[always] the case with wx-config. I admit I didn't think of using find(1)
but it surely doesn't seem to be a good idea on a multi GB filesystem.

GC> If options aren't suitable, then messages like
GC> 
GC>   #if wxUSE_THREADS
GC>   #   error Disable wxUSE_THREADS in wx setup.
GC>   #endif // wxUSE_THREADS
GC> 
GC> in 'wx_checks.cpp' seem clear enough to me,

 This wouldn't be that bad if this file were the first one to be compiled.
When I tried to build lmi for the first time, it finished half of the build
before spitting out this error which was hardly user-friendly. At least
with configure once it finished without errors you're entitled to expect
no configuration-related compilation errors.

GC> > 1. "make --help" won't give you possible values for CXXFLAGS but configure
GC> >    will give you --enable-debug
GC> 
GC> OTOH, reading the makefile will give you, for example,
GC>   build_type=mpatrol
GC> but configure won't.

 "./configure --help" will give you --with-mpatrol option, of course. And
while it's hard to argue that you can learn everything about the build
system from reading the makefiles, I can honestly tell you that it tells
much longer than scanning "configure --help" output.

GC> And even '--enable-debug' doesn't work with gnu 'hello', which is
GC> supposed to be a "model for all of the GNU coding standards":

 GNU coding standards don't include debug builds (GNU programmers must be
so good they don't ever need to debug their programs). I'm not sure what
does it prove about autoconf though?

GC> > 2. "-g" is not going to work for msvc (it needs "-Zi") and --enable-debug
GC> >    could hide it
GC> 
GC> But autoconf won't know that borland needs both '-v' in CXXFLAGS and '/v'
GC> in LDFLAGS.

 Well, yes, but the point is that this problem could be fixed once in
autoconf. Or everyone could continue writing mutliple sets of makefiles to
deal with it.

GC> > 3. you have to specify make parameters every time and this is painful if
GC> >    you recompile repeatedly -- with configure you normally just run it 
once
GC> >    and then just do "make"
GC> 
GC> To compile repeatedly, I just use command history.

 I love command history as well but it's still a solution for a problem
which doesn't exist with autoconf.

GC> I wouldn't mind including a 'user_configuration.make' file, if found,
GC> which would offer another way of setting persistent options; actually,
GC> that seems much better than testing for a fixed list of options in
GC> 'GNUmakefile', so I think I'll do that instead.

 This would be nice, yes.

GC> > GC> >    . possibility to build in another directory: this is much more 
tidy than
GC> > GC> >      building in the source directory
GC> > GC> 
GC> > GC> The lmi makefiles do that already.
GC> > 
GC> >  Sorry, I should have been more clear. What I meant was to build in any
GC> > other directory. E.g. a common situation is to have sources on an NFS
GC> > volume and then you really don't want to build on it so typically you'd
GC> > build in /tmp/foo using sources from ~/src/foo.
GC> 
GC> Then do this:
GC>   make build_directory='/tmp/foo'

 I didn't know about it. Ironically, this still proves another point of
mine: you do have to read the makefile to find this directory probably.
With autoconf, anybody having ever built a package from sources on a Linux
system knows that you can run configure from another directory. IOW, it's a
Unix standard -- and so anybody with Unix background knows how to use it.


 Regards,
VZ