GNOME Bugzilla – Bug 649775
glib-gio-gdbuscodegen-Makefile.patch
Last modified: 2011-05-11 20:19:56 UTC
Created attachment 187492 [details] [review] proposed patch The variables can contain spaces (in my case $(python) is set to '/usr/bin/env python'), so the sed commands should be quoted. This bug shouldn't be necessary at all, why is the var @PYTHON@ handled in the Makefile, but not used in the .in file. Furthermore, why was a homegrown sed solution used and not the default configure output mechanism?
-> gdbus component To answer your question, I believe I just copied some of this from gobject-introspection and it's not impossible I may have screwed something up in the process.
(In reply to comment #0) > Created an attachment (id=187492) [details] [review] > proposed patch > > The variables can contain spaces (in my case $(python) is set to '/usr/bin/env > python'), so the sed commands should be quoted. Makes sense. > Furthermore, why was a homegrown sed solution used and not the default > configure output mechanism? Because basically configure substitutions are designed to substitute Makefiles; e.g. "libdir" can output to $(prefix)/lib, which is not what you want for non-Makefiles.
If the only concern is the double evaluation of variables, then there is a macro for that: http://www.gnu.org/software/autoconf-archive/ax_define_dir.html While my patch fixes the immeadiate problem, using the standard autotool machinery for these kind of things would greatly increase portability of the build system over the use of one-off shell scripting solutions.
(In reply to comment #3) > using the standard autotool > machinery for these kind of things would greatly increase portability of the > build system over the use of one-off shell scripting solutions. That's nonsense; there is no portability issue here.
I wrote a commit message for you and pushed to git; thanks! For future patches please use "git format-patch" to create a patch with a commit message.