After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 456154 - Nonportable makefile constructs
Nonportable makefile constructs
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.13
Other FreeBSD
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-07-12 07:30 UTC by Yeti
Modified: 2009-12-20 12:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (part 1) (1.10 KB, patch)
2007-07-12 07:32 UTC, Yeti
committed Details | Review
patch (2.50 KB, patch)
2007-08-24 17:00 UTC, Yeti
none Details | Review

Description Yeti 2007-07-12 07:30:11 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 \
                $< >$@
Comment 1 Yeti 2007-07-12 07:32:27 UTC
Created attachment 91661 [details] [review]
proposed patch (part 1)

Fixes the glib-mkenum rules, $(gst_headers) can be easily used here instead of $^.
Comment 2 Yeti 2007-07-12 07:46:47 UTC
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.
Comment 3 Yeti 2007-07-12 09:52:47 UTC
> 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.
Comment 4 David Schleef 2007-07-13 00:32:25 UTC
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.
Comment 5 Yeti 2007-07-13 08:38:21 UTC
(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.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2007-08-23 07:10:54 UTC
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.

Comment 7 Jan Schmidt 2007-08-24 16:37:55 UTC
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.
Comment 8 Yeti 2007-08-24 16:55:01 UTC
(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.
Comment 9 Yeti 2007-08-24 17:00:53 UTC
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).
Comment 10 Jan Schmidt 2007-08-24 17:02:45 UTC
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
Comment 11 Tim-Philipp Müller 2009-06-08 23:11:05 UTC
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.
Comment 12 Yeti 2009-12-20 12:19:14 UTC
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.