Depending on external libraries

[Daniel Stone]

On Mon, Mar 15, 2004 at 09:51:31PM +0100, Egbert Eich wrote:
> 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.

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.

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

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.

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

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.

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

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

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

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

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

>  > Not always - look at the kernel, et al.
> 
> Right. One example where a group changed their build system without
> going to autotools.

Correct.

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

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.

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

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.

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.

:) d

-- 
Daniel Stone                                            <daniel at freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/release-wranglers/attachments/20040316/57d2ab01/attachment-0001.pgp