%% Angus Leeming <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
