On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh <rle...@codelibre.net> wrote: >> 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.
Adding support for auto linking to g++ (via pragma or some other way) doesn't mean g++ no longer conforms to SUSv3 or POSIX. >> 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. Works pretty well for Boost. >> > 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. It's a long-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. Isn't that exactly what I'm trying to achieve? > 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. I agree >> 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)). How about Windows? > 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. Again, I'm not saying pkg-config is bad. > 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. You're encoding it in the path instead, which seems worse. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiksrh519uyvz1nn5wyulob1ovn1myzonhq89...@mail.gmail.com
