On Wed, Jan 02, 2002 at 11:59:24AM -0600, Frederick Bruckman wrote:
> I noticed that all your buildlink.mk files include, as a matter of
> course, every buildlink.mk file for every package that the buildlink'd
> package depends on. This is really, really wrong.

If you find that is the case, then it is indeed wrong.  Buildlink.mk files
should only include other buildlink.mk files if the shared libraries from
one package depend on the shared libraries from the other package, e.g.
gtk/buildlink.mk includes glib/buildlink.mk.

> Take, for example, "libwww". Libwww requires "openssl" (on systems older
> than 1.5), in order to build and install libwwwssl.so*. No package that
> depends on libwww>=5.3.2nb1, however, actually links in libwwwssl, yet
> all depend on "openssl" by virtue of the recursion mechanism in the
> "package" target. Now when you upgrade openssl, or upgrade to 1.5.x, you
> can't just rebuild libwww and reinstall the packages that depend on it.
> You have to rebuild teTeX, and glibwww -- and therefore gtkhtml and most
> of gnome -- even though you will probably get identical binaries to ones
> in the (wrongly obsoleted) packages. In this case, including
> openssl/buildlink.mk in libwww/buildlink.mk just adds to the insult and
> increases the build-time and clutter under work/.buildlink.

In this particular instance, I recall that when I created
libwww/buildlink.mk, I noted that libwwwssl.so depends on libssl.so.  I
was unclear at the time how the libwww libraries were used, so I erred on
the side of caution and included the openssl/buildlink.mk file so that
package builds would work correctly.  If what you say about libwwwssl.so
is true, then we should remove the inclusion of openssl/buildlink.mk and
instead add it to the packages that use libwwwssl.so.  Please feel free to
make this change.

> Now consider "ee", which depends on lots of packages which it has no use
> for -- libxml, Mesa, ORBit, bonobo, glibwww, libwww, and oaf, including
> multiple wildcards for libxml and bonobo. None of these are direct
> dependencies; they're all complements of the recursion in "make
> package", based on the single dependency on "gnome-core". Previously,
> you could build this package against a slightly older version of
> "gnome-core", or "gnome-libs", and it would still work with the newest
> one. The point is, changes to the minor version of "liboaf" and
> "libORBit" aren't an issue, since the binary doesn't actually require
> them. Now, however, by virtue of recursive buildlink.mk includes, the
> package will depend on the very latest version of everything, even
> things it doesn't need at all. The package that you then have to go to
> so much trouble to build, will not be portable to systems that it should
> be portable to, because of these additional (bogus) dependencies.

The BUILDLINK_DEPENDS.<package> line in buildlink.mk files shouldn't change
whenever <package> is updated.  It only needs to be updated when the shared
libraries from the newer version break the ABI, which is usually signaled by
a bump in the major number on the shared library.  This is why, for example,
the glib/buildlink.mk file uses glib>=1.2.8 even though the glib package
itself as at 1.2.10.  If you find instances where the version number in a
buildlink.mk file was unnecessarily bumped, then they should be changed back.
Please feel free to make these changes.

> This is all a big step in the wrong direction. Even a mechanical change
> away from that would be good. I mean, if you were to take away all
> recursions in the buildlink.mk files, and present all the (formerly)
> recursively included buildlink.mk files in the Makefiles, at least the
> maintainer could delete the line once he finds it's not actually needed.

I don't think the problems arise if the above two points I made are followed.

	Cheers,

	-- Johnny Lam <jlam@jgrind.org>