Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/10/07, Ralf Wildenhues <address@hidden> wrote:
> * NightStrike wrote on Fri, Aug 10, 2007 at 12:00:21AM CEST:
> > On 8/9/07, Ralf Wildenhues <address@hidden> wrote:
> > > * NightStrike wrote on Thu, Aug 09, 2007 at 04:49:00PM CEST:
> > > >
>
> > Well, I don't want or need to do this exactly.  I was just
> > illustrating that I *could*.  I'll give a better example of something
> > that I'm doing with automake that I know is wrong but that I can't
> > figure out how to do properly.
>
> Ahh, you're going in the right direction: show what you want to achieve,
> not how you think it would be best to do it.


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

> in this Makefile.am, and
>   noinst_LIBRARIES = libfoo.a
>   libfoo_a_SOURCES = ...
>
> You could even hack like this (but I won't guarantee that it won't break
> with another Automake release):
>   AR = :
>   ARFLAGS = >

Again, same issue.  I need these tools to operate normally for a large
portion of the build process.  It's just a handful of things that are
obscure.

> > Specifically, the first gets compiled into both crt1.o and crt2.o, and
> > the second gets compiled into both dllcrt1.o and dllcrt2.o.  The
> > compilation options for XX1.o are the same, and the options for XX2.o
> > are the same.  I came up with this equally ugly workaround:
>
> I don't think this is all that ugly.  But I don't see why you should
> need BUILT_SOURCES, at least not from this snippet alone; you could just
> as well list those .o files as dependencies to all-local, or put them in
> some libexecdir_SCRIPTS or so.  And I think you can make use of COMPILE
> to your advantage, instead of using CC directly.

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.

Now, again, as I make that statement, please understand that I'm very
new to automake, and the only things I know about it I gleaned from
the manual and from experimentation.  I really don't have any
theory-based knowledge (ie, "Why is it done a certain way?")

As for your suggestion, I don't know what COMPILE is.  Reading manual....

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.

Now about the _SCRIPTS idea.  Someone else in this thread suggested
it, as well, so it would be foolish of me to not examine it much more
closely now that multiple people are thinking the same idea
independently.

Again reading the manual, I see these two statements:
"Automake does not assume that scripts are derived objects; such
objects must be deleted by hand (see Clean)."
That's an issue, but can be worked around

"Since automake appears in the AC_OUTPUT macro, a target for it is
automatically generated, and it is also automatically cleaned (despite
the fact it's a script)."
This implies that I should put crt1.o, etc in AC_OUTPUT to force
automake to handle more of the work?  I'm a little confused on that.


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:

crt1.o:
        $(CC) -c -D__CRTDLL__ -U__MSVCRT__ $(ALL_CFLAGS) $< -o $@
crt2.o:
        $(CC) -c -D__MSVCRT__ -U__CRTDLL__ $(ALL_CFLAGS) $< -o $@

dllcrt1.o:
        $(CC) -c -D__CRTDLL__ -U__MSVCRT__ $(ALL_CFLAGS) $< -o $@

dllcrt2.o:
        $(CC) -c -D__MSVCRT__ -U__CRTDLL__ $(ALL_CFLAGS) $< -o $@

Using the _SCRIPTS primary, I would replace CC in the above with
COMPILE, replace ALL_CFLAGS with AM_CPPFLAGS, and list all four
objects in lib_SCRIPTS.  Is that correct?  Would I then also place
these four targets in AC_OUTPUT?  autoconf doesn't know how to build
them, does it?  Is this more "automake-ish" than the BUILT_SOURCES
thing that I came up with?


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