Prev: Bill Cunningham and sockets for the past six years
Next: wait for particular process pid
From: William Ahern on 8 Apr 2010 14:43
Poster Matt <postermatt(a)no_spam_for_me.org> wrote:
> William Ahern wrote:
> > Poster Matt <postermatt(a)no_spam_for_me.org> wrote:
> > <snip>
> >> Thanks and I think I'll take a look at scons. I'm not doing well with the
> >> autotools.
> >
> > What are you building?
> >
> > Most of my projects use POM, which IMHO is far superior in the common case
> > to scons, autotools, CMake, et al.
<snip>
> I can't seem to find POM anywhere. Your last paragraph instructing me to 'man
> make' and 'info make' in conjunction with my inability to find GNU POM suggest
> to me that your post might be an elaborate joke (apologies if not) telling me
> that I should just stick with 'make'.

> Please confirm or deny joke status. :)

I wouldn't call it a joke, nor simply tongue-in-cheek. I honestly meant--and
believed--everything I said.[B

Another problem with these builds systems is that they get in the way. No
port or package maintainer relishes the idea of requiring CMake or scons or
waf or autotools--tho this is par--or whatever other build requirement there
is when porting software to a platform. The fact that it may generate
intermediate Makefiles doesn't help, either. It's particularly clear that in
these circumstances these things are more often obstructions than aids,
because they create walled gardens of build logic and mindshare.

Basically, a plain Makefile that respects the following variables helps
everybody and hurts nobody:

CFLAGS
CPPFLAGS
LDFLAGS
LIBS
DESTDIR
PREFIX
prefix
libdir
includedir
bindir
sbindir
sysconfdir

There are others that are less often used:

http://www.gnu.org/prep/standards/html_node/Directory-Variables.html

A lot of build tools provide special mechanisms to locate and specify
libraries and include directories, but anybody building your application
from source is probably well aware of how to specify the appropriate
variables in their environment. So trying to do it automagically and
possibly making it difficult to correct when its wrong can be more costly
than merely requiring that person to specify the appropriate parameters
manually. And these can always be provided for common environments anyhow.

Tools like libtool can be used directly, if desired. Someone mentioned
pkg-config, but pkg-config is an epic fail for some of my environments,
because I keep 3rd-party projects in entirely separate directories.
pkg-config is one of those tools that solves a problem by effectively
dictating a single solution; it circumscribes it's problem domain to
effectively exclude the hard cases, for which people assumed it was aid.
I've had to modify many builds which depended on pkg-config.

For compiler and interface issues, there are many ways to approach them.
First is to become familiar with the appropriate standards, including POSIX
and platform-specific feature test macros: _XOPEN_SOURCE, _GNU_SOURCE,
_BSD_SOURCE, _DARWIN_C_SOURCE, etc. You often have to do this anyhow for
dynamic feature test mechanisms in autotools, etc. The Linux kernel uses
nifty GNU Make macros like "cc-option" to test compiler flags.

If your application breaks in some obscure environment, the nature of open
source is that others will send you patches, rather than you prospectively
trying--and inevitably failing--to account for all cases. If your
application isn't open source, then odds are you're not worrying about
obscure environments anyhow.

For huge corporate projects that may have thousands of distinct components,
I've found that solutions like Apt and dpkg provide much more stability and
flexibility than trying to stitch together everything into a monolithic
build, using so-called non-recursive Make

http://www.xs4all.nl/~evbergen/nonrecursive-make.html

or other build systems that allow for a centralized configuration.

I've even hacked Apt and dpkg to run on an OpenBSD machine managing the
central package repo (and not, unfortunatley, to actually install the
packages on OpenBSD, though perhaps that would've worked, too).

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Bill Cunningham and sockets for the past six years
Next: wait for particular process pid