On Thu, Nov 17, 2011 at 2:06 PM, Alexander Neundorf <a.neundorf-w...@gmx.net> wrote: > On Thursday 17 November 2011, David Cole wrote: > ... >> If a project does something like this (distributes a file with >> build/install time information in it) but then lets the end user of >> the binary installation put it wherever they please...... then the > > that's what I hear from our Windows developers. > >> distributed files should not contain any build/install time >> information in them, > > But according to what I hard this is what is done... > >> but rather should parse and use their actual end >> user install location if they need to provide that information on an >> end user's system. > > ...instead of this. > I also don't know whether pkgconfig supports something like $ORIGIN to > reference its own location in pc-files, which might help. > >> It sounds to me like pkg-config is simply not suitable for use with >> packages that may be installed/copied anywhere. > > Same here. > >> What is the problem we are trying to solve? > > From my very private POV: > I'm reviewing the Find-modules we have in KDE. > Many of them do > > if(NOT WIN32) > pkgconfig stuff... > endif() > > Now, I do not know from personal experience whether this if() make sense or > not. > > If it does make sense, then it might make sense for any package. In that case, > it would also make sense to have a global solution for this (like an option > CMAKE_SKIP_PKGCONFIG_ON_WIN32), instead of having to put this if() in each and > every Find-module. > > If the if() doesn't make sense, then it can be simply removed, and pkgconfig > is used everywhere. But our Windows developers said they don't want that. > > OTOH, since the Find-module must also work without pkgconfig (since we cannot > rely on that it exists everywhere), one could also argue that pkgconfig is > unnecessary completely in Find-modules, but then another group of people > starts complaining that we are ignoring existing standards and they really > want to use pkgconfig. > > So, what I'd like to get, is first some more opinions and experiences with > this, and as result some reasonable guidelines how to use pkgconfig properly > (or not). > > Alex >
I think we should completely ignore pkg-config on the grounds that their packages are not re-locatable, yet there are some packages that allow relocation anyhow. It should simply be made clear to everyone that pkg-config packages must not be, cannot be relocated. Or, if we are wrong in this conclusion, somebody who cares about pkg-config as an "existing standard" should step forward and defend the inexplicable practice of relocating non-relocatable packages and then informing queriers of the old location... But..... if you insist on supporting pkg-config to appease those who would use it anyway despite this limitation, then I would vote for something like this: if(NOT DEFINED CMAKE_USE_PKGCONFIG) # Default to using it: set(CMAKE_USE_PKGCONFIG 1) # But not on Mac or Windows, where end-user relocation is common practice: if(APPLE OR WIN32) set(CMAKE_USE_PKGCONFIG 0) endif() endif() if(CMAKE_USE_PKGCONFIG) pkgconfig stuff... endif() up to 4 cents now, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake