Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/9/07, Ralf Wildenhues <address@hidden> wrote:
> * NightStrike wrote on Thu, Aug 09, 2007 at 04:49:00PM CEST:
> >
> > How do I individually override everything that takes place for a given
> > target?
>
> I don't think there is a general way to do that.  You can use 'make -n'
> if you wish to not execute commands, or override the RANLIB or AR or CC
> (or COMPILE) macros.

I guess what I meant is, we have, using the example in the automake
manual, maude_LINK and maude_AR.  Why not maude_CC, maude_RANLIB, etc?

> > For instance, I could, if I chose, do this:
> >
> > lib_LIBRARIES = libmylib.a
> > libmylib_a_SOURCES = source1.c source2.c
> > libmylib_a_AR = echo \!* > /dev/null
>
> Serious question: why do you want or need to do this?  Automake
> generally allows flexibility where it's necessary for portability
> but if you don't have ar, then libmylib.a can't be built; however
> AC_PROG_RANLIB will set @RANLIB@ to ':' for you if not present --
> not all systems have/need a ranlib.

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.

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:

noinst_PROGRAMS = dummy
dummy_SOURCES = \
  CRT_fp8.c CRT_fp10.c txtmode.c binmode.c crtbegin.c crtend.c
dummy_LINK = \
  @echo \!* > /dev/null

This causes make to try to relink all the .o files into dummy.exe
every time, but it's only an echo command, so the overhead is minimal.
 I'm left with the desired .o files that aren't linked together, but I
still have all of the dependency tracking that automake provides.  Now
to compound the issue, these files all need special CC commands:

crtexe.c crtdll.c

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:

BUILT_SOURCES = crt1.o crt2.o dllcrt1.o dllcrt2.o
crt1.o:
        $(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__CRTDLL__ -U__MSVCRT__ -c
$(top_srcdir)/crtexe.c -o $@
crt2.o:
        $(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__MSVCRT__ -U__CRTDLL__ -c
$(top_srcdir)/crtexe.c -o $@
dllcrt1.o:
        $(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__CRTDLL__ -U__MSVCRT__ -c
$(top_srcdir)/crtdll.c -o $@
dllcrt2.o:
        $(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__MSVCRT__ -U__CRTDLL__ -c
$(top_srcdir)/crtdll.c -o $@


So you see, I'm trying to find a better way to handle the uniqueness
of this project.  Now, keep in mind, I have never used automake
before, and my first attempt at it was to reverse engineer an existing
set of Makefiles into Makefile.am to generate the original Makefiles
(silly, I know).  I've been using the automake manual as a bible, and
have taken away much more from it that's even there, but obviously I'm
still missing some fundamentals here.  What I'm doing up above can
most likely be done in a better way -- I just don't know how.