Depending on external libraries

[Egbert Eich]

Daniel Stone writes:
 > 
 > Well, zsh was an arbitrary example. I had a shell script to run through
 > and build KDE's 20-something modules, plus Qt, that would run on any
 > POSIX shell.

OK.

 > > 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?
 > 
 > If you can come up with a list of options that vary, that would be very
 > useful - we can work from the list of what needs fixing.

Can we turn this around and create a registry for options?
This way we would collect all exisitng ones find redundancies
select the most self explanatory one and deprecate the others.

Can we get someone to volunteer to do this? I'm sure you are
more busy than you whish which is the same with me.

 > >  > 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. 
 > 
 > Right - _LTLIBRARIES builds a .a, a .so.X.Y.Z, and a .la (a meta-archive
 > of sorts).
 > 
 > > Do you also allow to build the profile version and/or the debug version?
 > 
 > I'm not sure how you build with profiles, but you could make a rule for
 > this, yes. I'm pretty sure there's a debug rule already.

OK.
 > 
 > > How about if you need a rule that doesn't exist in the automake world?
 > 
 > You can create it. :) autotools is designed to be extensible. KDE
 > extended it for moc, uic, and other generated files.

How? I have not found out yet.
Please don't say dot-rules. Dot rules are not very flexible as they
depend on an extent. If your file doesn't have an extent or you
have a build rule 'many files'->'single file' you cannot use dot-rules.

 > 
 > > - To create different docs from the SGML/XML whatever input?
 > 
 > See above, but I'm pretty sure it does most documentaiton formats
 > (including DocBook) natively.
 > 
 > > - To run things thru the preprocessor to allow for platform dependent
 > >   sections to be included/excluded?
 > 
 > This one's a bit trickier - you have to use Makefile logic, in some
 > cases (such as SBus support in Xizzle). The other option is to use
 > config.h, and have files only build what they need based on #define's.
 > Ugly, I know.

This is what cpp is used for in an X build. It can do marco replacements
and include/exclude sections on conditions. That's all we need. I'm not
hooked to cpp - m4 would be fine as well. But cpp does the job and is
available. 
If we can extend the rules to do this it would help a lot. Currently
the make rules for this are included directly in the Makefile.am in
X11. 
Imake does this by using a macro. If we have to change the build rule
(for example to use a different preprocessor) we do this in one single
place!) Believe me, I had situations where this came in extremely handy!

 > 
 > > - Other more complex build rules for a specific target?
 > 
 > See 'extensible'.
 > 
 > > - Have a build rule that creates a preprocessed file on request?
 > 
 > I'm not sure you can do this natively, but you could easily do it.

I've tired, there is not rule that does this at the moment.
I know I can always cut'n'paste the command line and add a -E option.
But doing a 'make foo.i' is so much more convenient. 

 > 
 > > - Have a build rule that provides the assembler output of the
 > >   compiler?
 > 
 > See above.
 > 
 > > - Allow to build .o files with debugging code stuff by doing
 > >   'make CDEBUGFLAGS=-g CXXDEBUGFLAGS=-g foo.o' (aka makeg foo.o)?
 > 
 > Hrm. You could do this, yeah.
 > 
 > >  > 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.
 > 
 > Yep - see 'personal belief'. We're violently agreeing on the same point:
 > changing build systems from what you're used to is difficult.

Definitly. 
My point here is that Imake is probably not more or less disgusting
than any other build environment. People like what they are used to.
You are trying to convince people who are used to Imake to switch.
This will take a little more than just saying '... everybody is using
autotools': people using Imake have tuned it to their needs over time.
Depriving them of their little anemnities without providing proper
replacement will not help to make them happy with the change.

 > 
 > >  > 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
 > 
 > I find ./configure --help, a lot easier than wading through config/cf,
 > wondering which option I need to set where, and to what.

That's true. However I find using config files a lot more convenient than
having to add the options to a command line one by one. I know, I can
create a small shell script, but this would be the same as asking you
to do a 'more config/cf/xf86site.def' :-/
 > 
 > >  > Not always - look at the kernel, et al.
 > > 
 > > Right. One example where a group changed their build system without
 > > going to autotools.
 > 
 > Correct.
 > 
 > > 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.
 > 
 > No, but if we're dragging out arguments on how easy something is to use,
 > ostensibly based on what the person's had experience with, then it's
 > safe to say that far, far more people will have trouble with Imake-based
 > systems than autotools, no? This also goes for distributors, as well as
 > end users.

I don't deny that. But what does it help if the end user gets what he's
used to but developers have to jump thru hoops?
There are many areas in X which post different requirements on the
build environment. People working on the libs have completly different
needs than those who work on drivers. They all need to be served. If
I cannot work on drivers any more as easy as I'm used to I won't do
it any more.
 > > I think autotools are a bastard of things to adapt to.
 > > The more I see of it the more I hate it. 
 > 
 > And me imake ... again, it's hard to adjust. We're agreeing with each
 > other 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.
 > 
 > I see things in autotools I badly miss in imake, such as easy
 > extensibility, feature rather than platform detection, a far lower
 > barrier to entry to the average person, run-time detection of
 > features/tests/whatever, and general familiarity to myself.

1. Extensibility: This is easy with Imake as you can add macros for
   about every build rule you may require.
2. Feature detection: There you definitely have a point. Therefore
   people have been proposing to add this to Imake using configure.
   Unfortunately nobody ever did. RMS at one time even wanted to
   pay somebody to do this. Unfortunately he 
   
 > 
 > I think the GPL stuff sucks, don't get me wrong (ask me what I feel
 > about the FSF some day), but I think the rules aren't a terribly bad
 > default to have; I'd say that well over 90% of all autotooled projects
 > are GPLed. That said, it should be asking rather than doing, but I don't
 > doubt we could get it changed.
 > 

;-) Right.

Egbert.