On 1/17/2018 12:31 PM, Carsten Schoenert wrote: > Hello Dan, > > Am 17.01.2018 um 16:51 schrieb Dan Weatherill: >> Carsten, >> >> The Findngspice.cmake script looks like a pretty standard (and pretty clean) >> implementation of how one is supposed to write find modules. There should be >> no >> need to provide debian specific modifications to it, and if there is it >> should >> be either provided by Debian ( as this is surely an issue for many >> packages), >> or it is a bug in cmake that it isn't respecting CMAKE_LIBRARY_ARCHITECTURE. > > yes, writing here something Debian specific would be the wrong thing. > The paths for the platform specific library isn't something only done by > Debian, I believe Fedora does a similar thing. > And other packages in Debian that uses CMake while package creation > working out of the box with libraries in multiplatform folders. > But Wayne hit the nail, CMake works here completely contrary to the > Autotools, I haven't keep that behavior in my mind. > >> As you can probably tell I don't have experience in Debian packaging, but I >> have packaged quite a few things for RPM based distros, and the need to >> patch >> standard-style find modules is extremely rare, granted that a lot of cmake >> variables needed are pretty obscure. > > Yes, and that was what made me surprised that other package working as > expected, but KiCad seems to be different here. But now it's all > working, you really need to delete all existing cached things. > > > Hello Wayne, > >> On Wednesday, 17 January 2018 15:46:41 GMT Wayne Stambaugh wrote: >>> Hey Carsten, > ... >>> Is this a clean config or did you run cmake on top of an existing >>> config? If it's an existing config, that is your issue. CMake caches >>> config values so it's picking up the cached library and header files. > > no, of course not, but your question is exact the point! :) > The configure script generated by the autotools is always testing and > generating all files while running. So I was expecting this behavior > here too.
I guessed this was the case looking at the variables because they are the same as my Debian box with a custom ngspice package that I made. It took me a while to get used to CMake as well. If you want the cache to get updated you have to call `cmake rebuild_cache` rather than rerunning the cmake configuration. > Now, after I have removed all existing old file it works out of the box! > > Based on the same message entries I got now the correct entries in the > variables. Great! Instead of saying thanks, you can buy me beer and FOSDEM. :) > >> -- NGSPICE_INCLUDE_DIR=/usr/include >> -- NGSPICE_LIBRARY=/usr/lib/x86_64-linux-gnu/libngspice.so >> -- CMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu >> -- NGSPICE_LIBRARY_PATH= >> -- NGSPICE_ROOT_DIR= >> -- CMAKE_LIBRARY_PATH= >> -- Found ngspice: /usr/include > > So the current behavior of the ngspice cmake helper is working also with > the prepared packages of libngspice from me and no direct action is > needed, but the error handling could be better. The error message if the > header or the library is missing could be more detailed. Right now one > error message for all cases is raised that is a bit misleading. > > I can try to improve this a bit. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
