help-make
[Top][All Lists]
Advanced

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

Re: Gnu make-isms


From: Paul D. Smith
Subject: Re: Gnu make-isms
Date: Wed, 3 Dec 2003 14:21:00 -0500

%% Angus Leeming <address@hidden> writes:

  al> They are. I'm talking about the LyX project www.lyx.org that uses the 
  al> autotools to its very core ;-)

The output that automake generates is 100% portable.  If you add your
own rules then you have to make sure they're portable.

  al> I'm pretty sure that we try not to use VPATH. Am I right in saying
  al> that automake does not use it in its built-in build rules?

If you are building outside of the source tree, then the auto* tools
require a version of make with a working VPATH... basically, GNU make.

So, the _best_ case scenario would be you are able to write your rules
in such a way that it will work if you build inside the source directory
(run "./configure" instead of "../xxx/configure" or whatever) with a
non-GNU make.

But you'll never be able to get "full functionality", that is building
outside of the source tree, using anything but GNU make.  Other makes
just can't do this very well.

  >> .ui.C:
  >>        $(UIC) $(UICFLAGS) -impl $*.h $*.ui -o $@

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

Correct.

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

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

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

To me this seems equivalent to this:

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

That is, file.C could be built from file.h.  This seems like it would
still preserve everything you need in terms of prerequisite
declarations: when file.ui is updated you know that file.h will be
updated, and when file.h is updated you know that file.C will be
updated.

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

You can use $*.h

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

Can't do this with suffix rules either.


If you have to be able to do this type of thing you'll have to write all
these rules out explicitly.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

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