Depending on external libraries

[Egbert Eich]

Daniel Stone writes:
 > > Imake at least offers a nice uniform way of configuration of the
 > > entire X suite. In the modular environment every piece will have its 
 > > own configure options (which you cannot put into a file but have to
 > > specify on the command line!) - largely depending on the maintainers 
 > > preference.
 > 
 > Sure. Unix provides us with scripting ability for a reason. Put it into
 > a file - just one that gets run by zsh/Python/whatever, rather than cpp.

zsh/Python may not be available everywhere. cpp is a prerequisite to 
build C code in the first place.

 > 
 > > In the past I found the configuration of autotooled projects rather
 > > cumbersome: on quite a few the options changed from version to version.
 > 
 > Sure, but that's a problem of process, not a failure of the entire
 > system. All that means is that a couple of people need to get their act
 > together and standardise options.

I'm not suggesting that the entire system is failing. And you are right
that some standardization needs to take place - not necessarily worldwide
but lets start with the community around this project.
Some build systems force people to do this, others allow them to 
go their independent ways. autotools seem to do the second.
So how do you propose to go about this?
 > 
 > I've found Imake to be pretty inconsistent in some respects, BTW -
 > sometimes it's BuildFoo NO, sometimes it's HasFoo YES, sometimes you
 > need to specify a path, sometimes it's any combination of the 3.

Right. Some people 'haven't gotten their act together' here either.
This could also have been fixed.

 > 
 > > What is more: as I developer I have been able to more freely among the
 > > different pieces of X without being plagued by the 'boundaries' of the
 > > build system: I had a uniform set of build rules. Now every piece will
 > > be created according to the author's preferences. Some will use automake,
 > > others will create their Makefile.ins directly.
 > 
 > Sure. Not everyone needs automake.
 > 
 > > A lot of packages will have the same problem solved in many different
 > > ways. The centralized structure of Imake provided a uniform way of doing
 > > things. If you discovered the way was broken you fixed it in one single
 > > place.
 > 
 > Which problems do you refer to? Most Makefile.am's are this simple:
 > lib_LTLIBRARIES = foo.la
 > foo_la_SOURCES = foo.cpp
 > bin_PROGRAMS = bar
 > bin_SOURCES = bar.cpp
 > bin_LIBADD = foo.la

Seems like you have rules to build the shared and static version of the
lib. 
Do you also allow to build the profile version and/or the debug version?
How about if you need a rule that doesn't exist in the automake world?
- To create different docs from the SGML/XML whatever input?
- To run things thru the preprocessor to allow for platform dependent
  sections to be included/excluded?
- Other more complex build rules for a specific target?
- Have a build rule that creates a preprocessed file on request?
- Have a build rule that provides the assembler output of the
  compiler?
- Allow to build .o files with debugging code stuff by doing
  'make CDEBUGFLAGS=-g CXXDEBUGFLAGS=-g foo.o' (aka makeg foo.o)?

 > > I think this is a myth. xf86site.def contained a list with a detailed
 > > discription of the most importand ones. People who felt that options 
 > > were missing could have spoken up.
 > 
 > I honestly didn't feel it was worth it. My personal belief is that the
 > XFree86 Imake-based build system is so crufty and disgusting it's
 > completely unworkable. I've spent too much time chasing up its random
 > nuances to like it.

Aha.
But I feel the same way about autotools. Every time I had to deal
with them (as a user!) I ran into issues that my blood pressure went
up.

 > 
 > The modular system does have this in its favour: with smaller modules,
 > it's impossible to get a build system as unusable as XFree86's.
 > 
 > This is me speaking as a distributor, as a developer, as an end user, as
 > someone who's watched helpless, hopeless, end users try to build it to
 > no avail many a time.

This is surprising: I unpack the tree, do a:
     make World
that's it. Do you expect that people who cannot do that can run
     ./configure; make

 > > 
 > > Looks to me this depends very much on the environemnt somebody is
 > > working in. On Linux people are used to huge chains of tools which
 > > themselves require more meta tools.
 > 
 > Not always - look at the kernel, et al.
 > 

Right. One example where a group changed their build system without
going to autotools.

 > > I myself find it rather cumbersome to track down problems to the
 > > part of the tool chain that's responsible - especially in an environment
 > > that attempts to do everything automagically.
 > 
 > I found this with Imake - I guess it's what you're used to. I think it's
 > fair to say there are far more people used to autotools than there are
 > imake, no?

So you want to force everybody to do the same thing?
The argument 'you should do foo because everybody is doing foo'
not very convincing. With the same argument you could convince
me to use Windows.

 > 
 > > I feel I'm there to do development not to learn and debug huge build
 > > environments and make them suite my purposes. And I don't want to be
 > > hampered by those problems an blocked from doing my work until I've
 > > convinced some toolchain guru to look into my problem.
 > 
 > Yeah, and this is what frustrated the crap out of me with imake. :) I'm
 > used to autotools, you're used to imake. Whenever there's a change,
 > people are going to have to adapt, and imake is a bastard of a thing to
 > adapt to. I had the same problems you did when I moved over from KDE
 > (autotools) to XFree86.

I think autotools are a bastard of things to adapt to.
The more I see of it the more I hate it. 

 > 
 > > To me it looks like we are abandoning the KISS principle here.
 > 
 > KISS is nice, sure, but to me it's losing sight of the ultimate goal a
 > little. KISS was put in place as a mechanism to ensure software was good
 > and didn't hobble you, right? But what happens when your software
 > becomes so simple it's hobbling you? Haven't you blindly followed a
 > means to an end so far that you're no longer going towards the end at
 > all?

I don't see where this is the case. 
I agree that certain features from the autotools are useful and
that are lacking from imake.
However having things like automake which has a few standard
build rules hardcoded plus a bunch of rules to keep RMS happy
isn't exactly what I'm missing in imake.

Egbert.