Re: any good development-oriented includable .mk files out there?

[Greg Chicares]

On 2006-2-10 14:07 UTC, Robert P. J. Day wrote:
>   ok, let me ask that again in english.  i have several C and
> shell-based projects, on top of which i've written numerous .mk files
> for inclusion to do things like take a bunch of sources and create,
> say, a shared library out of them.
[...]
>   i've written most of those myself and they seem to work fairly well,
> but i'm wondering if there's a standard set of makefiles like this
> somewhere.

Well, there's autotools.

There's some carefully-written, reusable code in Paul's white papers,
though I don't think it's factored in quite this way.

I think many practioners have their own personalized set of includible
submakefiles. For example, I have my own 'autodependency.make'. It
started out as a copy of something in one of those white papers, which
Paul credits to Tom Tromey (autotools again). It has various layers of
"enhancements" to deal with
 - various msw "shells"
 - compilers other than gcc
 - some cygwin difficulty
 - a defective piece of hardware that I've since replaced
 - changes in gcc's cpp options like '-MT' and '-MDD'
There's a leaner, more comprehensible implementation trying to
escape from this morass, but I haven't had the time to liberate it.
Even so, it wouldn't meet everyone's needs.

>   for instance, in a directory full of sources, i might have a single
> Makefile which contains, among other things:
>
>       ...
>       SRCS = foo.c bar.c fubar.c
>       include sharedlib.mk
>
> at which point "sharedlib.mk" will kick in and, naturally, use
> whatever is in ${SRCS} to build a shared library.

At one extreme, there's

  %$(SHREXT):
        $(LD) -o $@ -shared $^ $(ALL_LDFLAGS)

which is all I need on a particular project, but I confidently
suppose it's not versatile enough for your purposes. Another
extreme is attributed to autotools here:

http://lists.boost.org/Archives/boost/2002/01/22553.php
| > I gather from the list archives that the auto-* tools were considered
| > but discarded long ago. I guess that jam is going to have to be
| > taught all the things that libtool knows about building shared libraries.
|
| How hard can that be (he says glibly about a 5000-line shell script)?
| Seriously, though: how many details /are/ there to get right? As arcane as
| jam code can be, it's lots more expressive than shell script. I think it
| should be possible to duplicate this logic in far less code.

Maybe it's a quest for a holy grail.