GNOME Bugzilla – Bug 456154
Nonportable makefile constructs
Last modified: 2009-12-20 12:19:14 UTC
GStreamer fails to build with FreeBSD make due to non-portable Makefile constructs used for glib-mkenum rules (use of $^), and then again in the tools man page build which uses %-@GST_MAJORMINOR@.1: %.1.in sed \ -e s,gst-feedback,gst-feedback-@GST_MAJORMINOR@,g \ -e s,gst-inspect,gst-inspect-@GST_MAJORMINOR@,g \ -e s,gst-launch,gst-launch-@GST_MAJORMINOR@,g \ -e s,gst-typefind,gst-typefind-@GST_MAJORMINOR@,g \ -e s,gst-xmlinspect,gst-xmlinspect-@GST_MAJORMINOR@,g \ -e s,gst-xmllaunch,gst-xmllaunch-@GST_MAJORMINOR@,g \ -e s,GST_MAJORMINOR,@GST_MAJORMINOR@,g \ $< >$@
Created attachment 91661 [details] [review] proposed patch (part 1) Fixes the glib-mkenum rules, $(gst_headers) can be easily used here instead of $^.
The second issue is typically dealt with by using @GST_MAJORMINOR@ in the templates and adding them to AC_CONFIG_FILES() in configure.ac. If you want also a rule that rebuilds these files when the a template changes, you can do something like %-@GST_MAJORMINOR@.1: %.1.in cd $(top_builddir) \ && ./config.status --file=tools/$*-@GST_MAJORMINOR@.1:$*.1.in which will rebuild a file using config.status and non-portable make constructs, but these will affect only people editing the templates now, not everyone compiling gstreamer. Alternatively, the rule above can be easily expanded for each file manually resulting in a completely portable Makefile.
> Alternatively, the rule above can be easily expanded for each file manually > resulting in a completely portable Makefile. In fact, automake will create these rules for files in AC_CONFIG_FILES() automatically. I'm not sure one can get AC_CONFIG_FILES() working with the versioning though. If it can't be done, manual rules foo-@GST_MAJORMINOR@.1: $(top_builddir)/config.status $(srcdir)/foo.1.in cd $(top_builddir) && $(SHELL) ./config.status --file=$(subdir)/foo-@GST_MAJORMINOR@.1:$(subdir)/foo.1.in can be sill used.
If it could be done in AC_CONFIG_FILES(), it would be. It can't. The $< >$@ construct has been around since BSD 4.2. It shouldn't need to be changed. The patch, of course, is correct.
(In reply to comment #4) > The $< >$@ construct has been around since BSD 4.2. It shouldn't need to be > changed. The problem is of course not in $< and $@ but in the use of %-patterns that are GNU make extension. The rule does not match at all and the build stops because it cannot create the man pages.
I keep it open because of the pattern rule. 2007-08-23 Stefan Kost <ensonic@users.sf.net> patch by: David Nečas <yeti@physics.muni.cz> * gst/Makefile.am: Replace some non portable makefile constructs.
This patch is not, in fact, correct - it breaks make dist. $^ is the list of pre-requisites, *including* the directories they were found in. Using gst_headers makes it so that enum generation during the dist breaks because the sources are being pulled from ../../ common/glib-gen.mak also makes use of $^ for enum generation so however it is fixed here will also need to be applied there. In the meantime, I'm going to revert the patch.
(In reply to comment #7) > This patch is not, in fact, correct - it breaks make dist. Do you mean distcheck, particularly VPATH builds? If it also breaks `make dist', please explain. > $^ is the list of pre-requisites, *including* the directories they were found > in. > Using gst_headers makes it so that enum generation during the dist breaks > because the sources are being pulled from ../../ > > common/glib-gen.mak also makes use of $^ for enum generation so however it is > fixed here will also need to be applied there. > > In the meantime, I'm going to revert the patch. I see. Unfortunately, for tools that do not have any concept of input file search paths the only portable solution seems to be to add an explicite $(srcdir)/ to every input file. This results in minor visual clutter in non-VPATH builds (each file is addressed as ./file instead of just file) and medium clutter in the Makefiles.
Created attachment 94274 [details] [review] patch This illustrates what I mean (I'd rather do :s/// on the header list though as it does not depend on the exact header set).
Right, I mean distcheck, of course. I'm ok with the option of adding srcdir explictly, although it'll probably be a pain to disperse that everywhere it is needed
Can we close this? We explicitly require gmake now, and even if we didn't I doubt anyone will ever care enough to fix all our stuff up and keep it working. It's not like this stuff isn't painful enough already without the portability issues to consider.
Whatever you feel apropriate... It's funny how people suffer all the uglines, complexity and fragility of automake that stem from the portability to every silly make implementation out there -- only to declare GNU make is required anyway because they don't bother to write their own rules portably.