Re: Overriding all commands in Makefile.am

[Ralf Wildenhues]

* NightStrike wrote on Sat, Aug 11, 2007 at 04:42:39PM CEST:
> 
> > > For a particular project, there are a handful of .c files that need to
> > > be compiled to .o files and installed as .o files, not linked into any
> > > executable.  I came up with this ugly workaround:
> >
> > Well, I think the cheapest and least error-prone operation is the
> > creation of a static library.  Unless you need it otherwise, set
> >   RANLIB = :
> 
> I need RANLIB for many other things in the makefile.

Oh well.  You could put building these objects in a separate Makefile,
or just live with the small extra cost of building a library.

> This would be
> great if I could override ranlib on a per-target basis like I can with
> "maude_a_AR" and "maude_LINK".  Is there any reason why RANLIB doesn't
> follow the model of AR and LD?

I think the pressure hasn't been big enough yet, nor has a patch been
proposed.

> Wow, lots of stuff here.  Ok, first, thanks for thinking it's not that
> ugly.  I thought it was simply because "BUILT_SOURCES" is mainly
> geared for building sources.  Granted, it can be extended as per the
> manual's claim of it being a misnomer to build anything that has to be
> built first, but anything you build with BUILT_SOURCES won't have the
> same consistency checking as anything else.  For instance, there's no
> "mv ./deps/foo.Tpo ./deps/foo.Po" or anything like that.

Hmm, well yes, dependency tracking doesn't work the way you wrote those
rules.

> Ok, it would appear that $(COMPILE) is more in the automake domain,
> while $(CC) is more in the make domain.  So really, I should have been
> using $(COMPILE) to begin with if I want to keep as much as possible
> in the automake domain.  I'll change that.

Actually, you may want to stay out of Automake undocumented internal
details as much as possible, while using as much functionality as
possible; $(COMPILE) however is documented; the _SCRIPTS idea may be
construed as slightly undefined, but happens to work.

> For clarity, these are the original Makefile rules that I'm trying to
> convert to the automake domain so that automake dumps out a Makefile
> that does essentially the same thing:

FWIW, you should be able to just keep the original Makefile rules in
your Makefile.am: except for the occasional macro rename that comes with
Automake's style, rules should just continue to work.  That's by design
and not by accident.

> Honestly, I think what I really need is just a _OBJECTS primary.  Does
> / Will such a thing exist?

Somebody sent a patch to a similar end a while ago.  At the time the
need was not deemed worthy enough, I think, or/and the patches needed
more work.  Actually building the convenience library isn't a lot of
overhead, esp. not with the kind of objects you're aiming at (I assume
they are small).

Hope that helps.

Cheers,
Ralf