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 68969 - Simplify Makefiles
Simplify Makefiles
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
1.3.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-01-17 22:52 UTC by Raja R Harinath
Modified: 2011-02-04 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simplify Makefiles (6.34 KB, patch)
2002-01-17 22:53 UTC, Raja R Harinath
none Details | Review

Description Raja R Harinath 2002-01-17 22:52:44 UTC
This patch drastically simplifies gdk/Makefile.am and gtk/Makefile.am.

The Makefiles should work well with automake 1.5, and with older versions
of automake.  Most of the automake conditionals are removed, thus clearing
up the differences in behaviour between automake 1.5 and previous versions.

There's also a couple of bugfixes.  The makefiles originally used to pass

  -rpath @prefix@/lib

to libtool.  This is really broken and ugly and broken and ugly.  You can use

  -rpath $(libdir)

which is where the files are being installed, anyway.
Comment 1 Raja R Harinath 2002-01-17 22:53:17 UTC
Created attachment 6430 [details] [review]
Simplify Makefiles
Comment 2 Owen Taylor 2002-01-18 00:16:32 UTC
Is this "should work with older versions" of automake as
in "you expect it to", or as in "you tested it and it
does"? I'm pretty sure that the reason for doing things
this way is that you get "invalid unused variable" warnings
or something like that if you do it the simple way and
have blah_la_SOURCES/LIBADD variables that aren't referenced
in any blah_LTLIBARARIES variables.

It's conceivable that that was only with pre-1.4 automake
or something, but I seem to remember seeing it pretty recently.

The include and libdir changes are obviously fine.
Comment 3 Raja R Harinath 2002-01-18 01:17:34 UTC
I would be very very surprised if it doesn't work.

All the variables and libraries are out there in the open.  Nothing
hidden behind some conditional or the other.  The suggested usage has
been supported in automake for ages, long before conditionals were
introduced.  This used to be the only way to build one library out of
many possible ones.  Look at the discussion of EXTRA_PROGRAMS in
automake.info.

On the surface, there weren't any immediate problems when I tried. 
Not a peep from /usr/bin/automake (version 1.4).  The makefile looked
good when I eyeballed it.

However, my build broke due to a libtool version mismatch that'll take
me some time to fix.  I would appreciate it if you could try it out on
your setup.

BTW, the "unused variable" stuff is likely to be unrelated.  It was
introduced in a recent 'automake', and likely complains about the
G_MODULE_LDFLAGS (which is AC_SUBSTed in configure.in).
Comment 4 Raja R Harinath 2002-01-18 01:24:45 UTC
One thing I missed mentioning: I've had a variant of this patch in my
tree for 8-9 months, I think.  It has worked flawlessly so far through
my various updates of automake.
Comment 5 Owen Taylor 2002-01-18 01:45:18 UTC
Ah, the addition of EXTRA_LTLIBRARIES by Tor a few months
ago is the missing ingredient here to explain why this
works. When I initially set this up, one of:

 A) EXTRA_LTLIBRARIES didn't work with the version of 
    automake I was using then.
 B) EXTRA_LTLIBRARIES did work, but I didn't realize you
    could do that as well as EXTRA_PROGRAMS.

B) is more likely, but I'll pretend it might have been
A) for vanity reasons. Anyways, indeed it works fine with
my automake-1.4 setup and should be OK to commit.
Comment 6 Raja R Harinath 2002-01-18 04:28:12 UTC
Applied.  Thanks.