Enrico Weigelt wrote: > * Russ Allbery <r...@debian.org> schrieb: > > You're basically saying that people aren't allowed to use > > the typical Autoconf semantics of honoring --with and --without
> They should use --enable-*/--disable-* flags for switching features. --with and --enable have different semantics, although they're often misused and/or confused by upstream authors. See (autoconf)External Software' and the subsequent node, `(autoconf)Package Options'. > Switching dependencies which silently enables/disables features is > a generally bad approach. Well, in my very humble experience, an optional dependency is there precisely to provide an optional feature. > > I disagree with requiring static libraries even with the exception that > > you list. In this day and age, I think static libraries are basically > > useless unless > > Building static libraries (additional to shared/dynamic ones) usally > is not a big task. I guess what Russ is trying to say is that they are completely useless if just one library package in the dependency chain doesn't provide a static lib. > And still many people need them. I seriously doubt that. Many Debian library packages have been gradually dropping static libraries in the past few years, and I don't recall complaints. I think the statement "many people need them" is an exaggeration. If someone really needs a static library, she is probably in a perfect position and has the necessary knowledge/skills to build one herself. As you say, that's easy :-). > > I strongly disagree with requiring pkg-config. > > Well, actually, I need it, eg. for clean sysroot'ed crosscompiling. But pkg-config is notoriously bad when cross-compiling... With pure Autoconf macros (used properly, and providing an extra argument for AC_RUN_IFELSE and friends), cross-compilation works out of the box. If PKG_CHECK_MODULES is used, the installer has to go through extra hoops. > > None of my libraries support this, > > Bad. You should fix this. I don't think so. It's entirely his prerogative whether to support it or not, and it's perfectly fine not to use it. > > and I don't see any point in using pkg-config if the way that one > > uses the shared library is to just add -l<library-name>. > > Because that doesn't always suffice. It requires that the library > is in the toolchain's standard search path. That's the case with pkg-config too. If you install a library in /opt/foo, pkg-config will not find it if you don't instruct it to look there. > And what about cflags ? What about dependencies ? What's wrong with checking for the libraries/headers in the right dependency order? Honestly, I've always wondered what's so attractive in pkg-config that people use it so much. All it does is parsing a .pc file, which fails short in so many situations... The version check pkg-config does is simply a comparison with the version embodied in the .pc file, which does not match the reality in some cases, and more importantly, is the wrong approach -- the version check may succeed, but the library may not provide the feature needed by the package (improper installation, distro patch, sysadmin patch, forked software, anything else the package developer *has not* anticipated). And vice versa, which is equally annoying -- the library provides the symbol (or the new feature) the package needs, but the .pc file still contains the old version, because usually it's bumped at release time. Ugh. You are basically right that using pkg-config is easier for many upstreams, but "easy" != "correct". Correctness is far more important. I also fail to see what has pkg-config to do with distro-friendliness. A distro maintainer by definition should be familiar with the code, follow upstream development, examine diffs between upstream releases (in the ideal case), and add the appropriate build-dependencies when the new upstream version of the package needs them (or could benefit from them). pkg-config is not in the picture at all. > > It's a nice-to-have if upstream wants to bother, but is absolutely > > not required. > > For my setups, it *is* required. Then you probably can't build lots of packages. Many widely used libraries with a truckload of reverse dependencies do not support pkg-config, and there's nothing wrong in that. > > My packages will not be using pkg-config when pkg-config doesn't > > do anything useful or when I can reproduce its results in more > > supportable ways. > > Then you'll have to live with the fact, that other people won't > like your libraries very much, for that reason. That is an utterly wrong assumption, and I even find it slightly insulting because it presumes that the quality of Russ' software is somewhat lower than expected. > > The pkg-config Autoconf glue is ugly and does not properly > > implement Autoconf semantics (for example, it incorrectly merges > > CPPFLAGS and CFLAGS, and LIBS and LDFLAGS, and is not written > > using modern Autoconf features and style), Very true. > Nobody is forced to use them. Fortunately. -- 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/87k4mkb599.gnus_not_unix!%ya...@gnu.org
