Depending on external libraries

[Egbert Eich]

Kaleb S. KEITHLEY writes:
 > Oh, of course I could always just go track down the expat source, build 
 > it, and install it. (So please don't bother to tell me that that's all I 
 > need to do.)
 > 
 > You guys that are pro-modular-tree keep citing "how easy it (the modular 
 > tree) makes things for people who want to work on the source." Well, 
 > having these dependencies in the monolithic tree makes things easier 
 > too. As big advocates of "making things easier" as you are, I expect 
 > this argument will make perfect sense to you.

I guess those who have those packages prepared by their OS vendors
and installed on their systems by default in the latest stable versions
don't feel the pain of those who don't.
If we look at bugzilla #302 we see that Roland Mainz has difficulties
to get the Xorg bits build on a SUSE 8.2 which has a freetype version
that's over a year old.

While it may be simple to obtain later versions of those libs, and build
them it may not be possible to install them as one may not want to do
anything behind the back of the package database.
The monolithic tree on the other hand doesn't offer a convincing solution
either as it builds and installs the libs in /usr/X11R6/lib which may not 
conflict with ones recorded in the package database but may not help the 
user either as the system ones will usually come first in the user search 
path.
The only way out to help people who need to supply these things even
for older systems would be to offer a convenient way to link against
such libs (provided in the build system) statically.
So far I have not found anything about tuning the behavior of autobuild
by configure options convenient.

 > 
 > Having the build automatically build them too also makes things easier.
 > 
 > Asking people to edit their site.def or host.def to not build something 
 > isn't asking too much IMO if a system already has the needed dependency. 
 > That's a heck of a lot easier than having to hunt down the source for 
 > something, build it, and install it.

There is still the problem of 'maintaining' those libs in the monolithic
tree. It is straight forward to 'drop' them into the extras/ directory.
Therefore maintaining them pretty much boils down into integrating this
into the Imake build environment since this may require tweaking the 
Imakefile every time we 'drop in' a new version.

 > 
 > If it takes a little more work for "us" to make it easier for our 
 > "customers" then the choice should be obvious.
 > 

I'm not even convinced of that. If 'us' are the developers I expect it
to be as convenient as it can be. I don't want to be slowed down in
my work by the build system any more than strictly necessary. The build
system is my tool not my 'master'. And we must not forget that developers 
working on different areas may have different requirements.

Egbert.