Re: Gnu make-isms

[Angus Leeming]

Paul D. Smith wrote:
>   al> this might sound like a strange thing to ask on this list, but
>   I'd al> like to remove some gnu make-isms from the Makefiles I'm
>   al> maintaining.
> 
> Good luck with that :-/.

Hello, Paul.

> Before you go any further, though, sit down and decide what your
> real goal here is: what versions of make do you want to be portable
> to?
> If the answer is "all of them", stop what you're doing right there,
> go out and download and invest in getting autoconf and automake set
> up for your project.  

They are. I'm talking about the LyX project www.lyx.org that uses the 
autotools to its very core ;-) I recently tried to use Dec's make to 
build the source and it _almost_ worked. Only these 'unusual' build 
rules caused it to choke.

Maybe it would help if I attached the offending Makefile.am files? 
They are about 1kB in size in total.

>   al> %.C: %.h %.ui
>   al>         $(UIC) $(UICFLAGS) -impl $^ -o $@

>   al> However, the second rule is more complex and
>   al> I'm stuck.
> 
> There is no way in make suffix rule syntax to emulate the above rule
> completely.

I knew you were going to say that :-(

>   al> 2. The .C file also depends on the .h file -> '.ui.C: $*.h'
>   ???
> 
> No, this is not valid syntax.  Automatic variables like $* are
> available only within the command script, not in the prerequisites
> list.

and I suspected that that was going to be the case.

> The $^ variable is not available in standard make (although I
> thought SysV make had it... but maybe not).

> $< is not what you want: that's the first prerequisite only, not all
> of them.

>>From the above I also assume you're using VPATH: you couldn't get
>>that result given that pattern rule if you weren't.
> 
> VPATH is not part of standard make, and the SysV implementation of
> VPATH is brain-damaged.  You'll probably not be able to use VPATH
> in a portable makefile.

I'm pretty sure that we try not to use VPATH. Am I right in saying 
that automake does not use it in its built-in build rules?
 
> If you weren't using VPATH I'd say you have to do this:
> 
>  .ui.C:
>          $(UIC) $(UICFLAGS) -impl $*.h $*.ui -o $@
> 
> but, since you are using VPATH that won't work.

The problem with the above is that make has no way of knowing that the 
generation of the .C file is dependent upon the existence of the .h 
file.

Let's start again and express clearly what I am trying to do.

I have a .ui file from which I generate both .C and .h files in two 
separate steps:

file.ui --> file.h
file.ui,file.h --> file.C

One way forward would be to say that this can't be done portably using 
make syntax, so let's use a little shell script instead. Something 
like this in the Makefile:

.ui.C
        sh my_ui_converter.sh $(UIC) $(UICFLAGS) $< $@

where my_ui_converter.sh is simply:
#! /bin/sh
UIC=$1
UICFLAGS=$2
file_ui=$3
file_C=$4
file_h=`echo ${file_C} | sed 's,C$,h,'`
$(UIC) $(UICFLAGS) ${file_ui} -o ${file_h}
$(UIC) $(UICFLAGS) -impl ${file_h} ${file_ui} -o ${file_C}

Any further thoughts about doing that in the Makefile itself? I guess 
the trick is simply to generate the name of the .h file from '$@'.


Moving on, how about the second Makefile.am and this little gem:
%_moc.C: $(srcdir)/../%.h
        $(MOC) -o $@ $<

Hmm de dumm,
Angus

Makefile.am
Description: Text document

Makefile.am
Description: Text document