[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overriding all commands in

From: Ralf Wildenhues
Subject: Re: Overriding all commands in
Date: Wed, 15 Aug 2007 23:26:04 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

* 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

> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]