* 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
