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. 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. > -- 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. -- Regards Carsten Schoenert _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
