cross-platform portfiles and shlib extension

[RJVB (René Bertin)]

I notice that more and more port files check the current platform as if they're intended to function on other OS families than Darwin.

Yet as far as I can tell there is no central definition of the platform's shared library extension.

It would be useful to have one, so ports don't have to roll their own. Could be a fancy definition like

options shlibext
default shlibext {[expr {${os.platform} eq "darwin" ? "dylib" : "so"}]}

or a simple variable that gets initialised statically (set shlibext ...).

[ryandesign (Ryan Carsten Schmidt)]

Why would a port need that? It would be up to the build system to know how to build libraries for each platform.

[RJVB (René Bertin)]

Why would a port need that? It would be up to the build system to know how to build libraries for each platform.

Who said anything about the build systems? Have a look at the path-style depspecs used in many ports!

[ryandesign (Ryan Carsten Schmidt)]

Ah. Well, then ports should not use dylibs in their path-style depspecs. Any file installed by the port can be used, so any file whose name does not vary by OS would be a better choice than a dylib. When a dependency installs pkg-config files, that's what we typically use in the depspec when the reason for the dependency is library use. If no pkg-config file is provided, I suppose a header could be used. When the reason is the use of a binary, then that binary's path is used.

[RJVB (René Bertin)]

For fun, try

> fgrep dylib -R /opt/local/var/macports/sources/${TheTree} --include=Portfile --include="*.tcl" | egrep -v 'path:|install_name_tool'

I actually use MacPorts on Linux, and quite a few of the ports in my Linux-specific tree are just there because of the different shared library extension.