On Thu, Dec 09, 2010 at 02:00:24PM +0100, Olaf van der Spek wrote: > On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh <rleigh@codelibre.net> wrote: > >> I was wondering why you considered the auto linking stuff to be so horrible. > >> IMO the best solution would be to get auto link support into GCC too. > > > > It's non standard > > - it's not specified by ISO C > > - it's not specified by SUS/POSIX > > So? When we write code, we write it with the intention and expectation that it will be built using a standards-conforming compiler. I.e. one which implements the C and/or C++ language specification, and which also implements standard UNIX command-line options. While platform- specific features are provided by various platforms, the basic behaviour of the compiler and linker are specified by POSIX/SUS. As an example, look at the SUSv3 specification for the "c99" program (linked to gcc on GNU/Linux). How to compile and link a program is directly specified here. You can't change that without breaking a fundamental part of what a GNU/Linux system *is*. If it's no longer SUSv3 conforming, it's broken, because most of the programs built on Debian rely upon this standard. > > It's not portable > > - it uses vendor-specific #pragma magic > > > > It's fragile > > - every header must include the auto-link magic, either directly or > > indirectly. If you forget to do this just once in a single file, > > linking will break > > Sounds like an easy-to-solve hypothetical problem. Easy to fix once you notice a problem. The issue is how maintainable it would be in practice. i.e. how often will people break it when refactoring code, adding new headers etc.. It could be a significant burden. > > If it were incorporated into GCC, we still couldn't use it > > - it's not backward compatible with other UNIX compilers > > - it's not backward compatible with itself > > Who is we? > Do we need that kind of backwards compatibility? Yes, without a doubt. If this was used by a project as the linking mechanism, you wouldn't be able to build on any past release of Debian, or any other GNU/Linux distribution. You also wouldn't be able to build on any other UNIX system. It's not a feasible short-term goal. Such a change should really go via the standards committees if you really want support for such a feature. But this is a long- term solution, and would take years. Also, the standards committees tend to standardise existing practice, so an implementation of this behaviour in GCC and binutils (ld/gold) would be a prerequisite. As I mentioned at the top of this mail, standards conformance is a big deal. If we break that, we lose portability. If this is done through a revision to an existing standard (and SUS is probably the best place for this; the C/C++ standards don't AFAICT involve themselves in tool specs), support becomes much easier since it will be adopted across all conforming platforms. > > Now, pkg-config isn't standardised /either/, but it's useful because > > it will work with any standards-conforming compiler. It's just a > > generalisation of existing practice (in the form of foo-config > > scripts generated during a package build). > > Pkg-config probably isn't bad, but it does increase the complexity of > build script. Especially compared to auto linking. It integrates trivially with autoconf-using projects (PKG_CHECK_MODULES). It's also trivial to support in projects using plain make or other build systems (FOO_LIBS=$(shell pkg-config --libs foo)). But the main thing going for it is that it works with existing standards-conforming toolchains right now. It doesn't require adding non-standard compiler extensions. > > But this is all moot. I've written the pkg-config support into the > > auto-link header, and we just need to integrate it into the build > > system to get the job done. > > How does pkg-config handle the selection of the threading variant? > Toolset-variant? Seems it's hard-coded to a single variant. This is correct. The auto-link support could be adapted to encode the variant into the pkg-config .pc filename and/or the library names. Upstream specifically do not want to support multiple .pc files (see the upstream bug report and mailing list thread). People who do need this can build multiple versions, install them into different prefixes and then set PKG_CONFIG_PATH to select the variant they want at configure time. Unlike Boost, which has to support Windows, we can support multiple versions very easily without the need for encoding additional information into the library name. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature