Date: Thu, 27 Aug 1998 13:56:58 +0200 From: Martin Cracauer <cracauer@cons.org> To: Satoshi Asami <asami@FreeBSD.ORG>, cracauer@cons.org Cc: freebsd-ports@FreeBSD.ORG, vanilla@FreeBSD.ORG Subject: Re: Some -devel ports break autoconf (gtk11 spotted) Message-ID: <19980827135658.A25278@cons.org> In-Reply-To: <199808270102.SAA10629@silvia.hip.berkeley.edu>; from Satoshi Asami on Wed, Aug 26, 1998 at 06:02:19PM -0700 References: <19980826131115.C18242@cons.org> <199808270102.SAA10629@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199808270102.SAA10629@silvia.hip.berkeley.edu>, Satoshi Asami wrote:
> Specifically, which port are you talking about here? Does gtk11 put
> its gtk11.m4 in share/aclocal.current and gtk put its gtk.m4 in
> share/aclocal? And how do we fix other ports? (Why are they reading
> both files anyway?)
I'm not an autoconf expert as well, but my understanding is:
autoconf always reads all files in share/aclocal, but expects macros
not to be defined twice. Therefore it fails with both gtk files
installed. This could be fixed by renaming all macros in gtk11.m4.
The complexity for the application port builder would then explode,
because every program that uses autoconf (not an autoconf-generated
script) and looks for the gtk11 macros would have to replace these
macros as well.
> * > * While I'm at it, I also though it would be a good idea to create a
> * > * whoel $(PREFIX-DEVEL) directory structure, so that accessing two
> * > * version of one port would be easier. That is obviously limited to two
> * > * versions of a port, but would make compiling non-port software against
> * > * devel ports (i.e. GNOME against gtk11) much easier. Has this been
> * > * discussed before?
>
> You mean have something like /usr/local/devel where ports that have
> potential conflicts with system utilities (lesstif, octave, ncurses
> come to mind) install by default? That's an idea, but I'm not sure
> what that means in terms of two conflicting ports. (For instance, we
> put gtk in ${PREFIX} and gtk11 in ${PREFIX_DEVEL}, and are we going to
> swap them when gtk11 becomes the default? Won't that mess up people
> who already have one or the other installed and just try to rebuild a
> dependent port? The depednency rules should be taking care of this.)
OK, first of all, the scheme I propose for library ports works for two
versions of a port only, while the current one is unlimited. My
proposal will not use explicit version numbers for files names
(i.e. gtk11), but just one version with "-devel" and one without.
The key questions is: How do we maintain two different versions of a
library port so that an application using this library can choose one
of the versions?
The current scheme is:
- Move includefiles of the -devel version of the library port to a
different directory. /usr/local/gtk-devel
- Store the shared library in the normal place and use the shared
library version naming convention to seperate the older from the
newer library.
- Ignore the problem for static libraries.
- Ignore the problem for manpages.
- Other stuff (documentation) will be placed ad-hoc.
- No solution for aclocal files found.
Now, how does an application chooses one of them? Current Scheme:
An applikation port that uses the -devel library will
- be passed a ./configure option to look for gtk include files in a
nonstandard place.
- The Makefile will be modified to explicitly link against the right
version.
- In theory its configure script would have to be modified to use the
macros from the right aclocal file. As outlined above, that would
require changing all m4 macro names.
An application port that uses the non-devel library will
- have to be explicity linked against the older version of the shared
library. If it doesn't the port will fail when being compiled on a
system with both library versions installed.
Shortcoming of the current scheme:
- Heavy modifications needed for -devel-library using ports.
- Related, it becomes almost impossible to compile non-port sources
that need the -devel library version. You *have* to invest this
port-related work even for a plain ad-doc compile. I.e. this applies
for GNOME. The only other solution is to kick off the non-devel
library and symlink the devel library stuff to standard places.
- Catastrophic failiures when a non-devel ports fails to address the
right library in its Makefile, since it will use the newest, but
didn't use the -devel include files since these are stored
elsewhere. This is not a problem when only the non-devel library is
installed or for installing binaries.
- Manpage/infofiles problem, either overriding the non-devel ones or
being stored at a special place where standard tools don't search.
- aclocal/configure problem.
I think a different prefix for -devel libraries would be much
simpler.
Work to do for application ports:
For ports using -devel libraries:
- Change or give option to ./configure to look for includes and
libraries in $(PREFIX-DEVEL) first. This should also make it parse
aclocal files from there.
For ports using non-devel libraries:
- Nothing, it is even safe if no library versions are explicitly
linked agianst with because the newer libraries aren't in $(PREFIX).
The scheme is not perfect. For example, a aclocal problem arises in
that -devel using ports don't parse any from $(PREFIX)/share/aclocal.
What does this mean to the user?
- He needs $(PREFIX-DEVEL) for ldconfig. Doable from /etc/rc
- Since applications using -devel libraries can be installed to
$(PREFIX), he doesn't have to modify $PATH.
- If someone wants to read manpages or infofiles for -devel ports, he
has to manage the path himself. That can be expected from someone
tangling with -devel programming tools.
OK, now what happens when a -devel port becomes the default port and
an incompatible one becomes -devel?
Obviously, the former -devel version is has to be source-compatibel to
the former non-devel one, otherwise it can't replace the older one.
For applications installed as binaries: These link against one version
of the shared library. If the old version is removed, you loose, but
you can have as many version as you want. If $(PREFIX) and
$(PREFIX-DEVEL) are in ldconfig, no problem here when the libraries
move. $(PREFIX) should be earlier in ldconfig path.
For applications using the non-devel libraries, when compiled from
source: The former -devel library has to be source-compatible,
otherwise it can't replace the older one. The port doesn't need to be
modified.
For applications using the -devel libraries, when compiled from
source: This can fail when the new -devel is incompatible. The port
needs to be modified, all actions to use includefile and libraries
from $(PREFIX-DEVEL) has to be taken out. And the user is expected to
update the library and application ports at once. Since it is
unavoidable that anybody has to use its brain, I think its best that
it hits those people tangling with -devel libraries. These are most
likely to be able to.
A problem is the naming convention of shared libraries. Two numbers
are not sufficient. For example, the gtk-1.0.5 ports installs to
.so.1.5, while the 1.1 port to .so.1.1. This will crash when we are at
1.5 and is ugly anyway since you don't know what the newer library
is. Suppose 1.1 was -devel and becomes non-devel. Now we have .so.1.1
and .so.1.5 in $(PREFIX)/lib and ports newliy compiled will link
against the one with the highest version number, although the include
files installed are for 1.1. I'm afraid we need to solve this by using
a convention to bump the major number for each -devel->non-devel move
and the minor number increments discoupled from the actual version
number.
On the positive side, I think the two schemes are not
incompatible. Use $(PREFIX-DEVEL) for those port that needs it. But
nothing breaks several versions of library ports done the old way.
I'd like to add that in the case of gtk the old scheme is not as bad
as for other ports. The `gtk11-config --cflags|--libs` construct makes
building flawless. But the other problems still apply.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980827135658.A25278>