Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
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. 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. Thanks, Dan W On Wednesday, 17 January 2018 15:46:41 GMT Wayne Stambaugh wrote: > Hey Carsten, > > On 1/17/2018 5:14 AM, Carsten Schoenert wrote: > > Hello Dan, > > > > Am 16.01.2018 um 21:16 schrieb Dan Weatherill: > >> Hi Carsten, > >> have you tried specifying -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > >> when calling cmake in the build script? > > > > no I haven't until now, but this seems not to do anything. > > Even if I definitely have no parts of libngspice installed the cmake > > call works without error out. > > > >> Relevant documentation here, in roughly the 2nd paragraph: > >> https://cmake.org/cmake/help/v3.0/command/find_library.html > > > > I've looks several times into the documentation, after years it's still > > not really useful and easy to understand for me. > > > > I've done some small debugging right now. If I add the following message > > statements into the helper (right after the find_library call) I got > > output to variables that should be empty. > > > >> message( STATUS "NGSPICE_INCLUDE_DIR=${NGSPICE_INCLUDE_DIR}") > >> message( STATUS "NGSPICE_LIBRARY=${NGSPICE_LIBRARY}") > >> message( STATUS > >> "CMAKE_LIBRARY_ARCHITECTURE=${CMAKE_LIBRARY_ARCHITECTURE}") > >> message( STATUS "NGSPICE_LIBRARY_PATH=${NGSPICE_LIBRARY_PATH}") > >> message( STATUS "NGSPICE_ROOT_DIR=${NGSPICE_ROOT_DIR}") > >> message( STATUS "CMAKE_LIBRARY_PATH=${CMAKE_LIBRARY_PATH}") > >> > >> $ cmake .. -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > >> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_SCRIPTING_WXPYTHON=ON > >> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SPICE=ON -DKICAD_USE_OCE=ON > >> -DCMAKE_INSTALL_PREFIX=/home/carsten/tmp/kicad ... > >> -- NGSPICE_INCLUDE_DIR=/usr/share/ngspice/include > >> -- NGSPICE_LIBRARY=/usr/lib/libngspice.so > >> -- CMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > >> -- NGSPICE_LIBRARY_PATH= > >> -- NGSPICE_ROOT_DIR= > >> -- CMAKE_LIBRARY_PATH= > >> -- Check for installed Python Interpreter -- found > >> > >> $ LANG= ls /usr/share/ngspice/include > >> ls: cannot access '/usr/share/ngspice/include': No such file or directory > >> $ LANG= ls /usr/lib/libngspice.so > >> ls: cannot access '/usr/lib/libngspice.so': No such file or directory > > > > I'm quite sure there is something not correct in the cmake helper for > > ngspice. > > 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. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
Hey Carsten, On 1/17/2018 5:14 AM, Carsten Schoenert wrote: > Hello Dan, > > Am 16.01.2018 um 21:16 schrieb Dan Weatherill: >> Hi Carsten, >> have you tried specifying -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu >> when calling cmake in the build script? > > no I haven't until now, but this seems not to do anything. > Even if I definitely have no parts of libngspice installed the cmake > call works without error out. > >> Relevant documentation here, in roughly the 2nd paragraph: >> https://cmake.org/cmake/help/v3.0/command/find_library.html > > I've looks several times into the documentation, after years it's still > not really useful and easy to understand for me. > > I've done some small debugging right now. If I add the following message > statements into the helper (right after the find_library call) I got > output to variables that should be empty. > >> message( STATUS "NGSPICE_INCLUDE_DIR=${NGSPICE_INCLUDE_DIR}") >> message( STATUS "NGSPICE_LIBRARY=${NGSPICE_LIBRARY}") >> message( STATUS "CMAKE_LIBRARY_ARCHITECTURE=${CMAKE_LIBRARY_ARCHITECTURE}") >> message( STATUS "NGSPICE_LIBRARY_PATH=${NGSPICE_LIBRARY_PATH}") >> message( STATUS "NGSPICE_ROOT_DIR=${NGSPICE_ROOT_DIR}") >> message( STATUS "CMAKE_LIBRARY_PATH=${CMAKE_LIBRARY_PATH}") > >> $ cmake .. -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu >> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_SCRIPTING_WXPYTHON=ON >> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SPICE=ON -DKICAD_USE_OCE=ON >> -DCMAKE_INSTALL_PREFIX=/home/carsten/tmp/kicad >> ... >> -- NGSPICE_INCLUDE_DIR=/usr/share/ngspice/include >> -- NGSPICE_LIBRARY=/usr/lib/libngspice.so >> -- CMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu >> -- NGSPICE_LIBRARY_PATH= >> -- NGSPICE_ROOT_DIR= >> -- CMAKE_LIBRARY_PATH= >> -- Check for installed Python Interpreter -- found > >> $ LANG= ls /usr/share/ngspice/include >> ls: cannot access '/usr/share/ngspice/include': No such file or directory >> $ LANG= ls /usr/lib/libngspice.so >> ls: cannot access '/usr/lib/libngspice.so': No such file or directory > > I'm quite sure there is something not correct in the cmake helper for > ngspice. > 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. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
Hello Dan, Am 16.01.2018 um 21:16 schrieb Dan Weatherill: > Hi Carsten, > have you tried specifying -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > when calling cmake in the build script? no I haven't until now, but this seems not to do anything. Even if I definitely have no parts of libngspice installed the cmake call works without error out. > Relevant documentation here, in roughly the 2nd paragraph: > https://cmake.org/cmake/help/v3.0/command/find_library.html I've looks several times into the documentation, after years it's still not really useful and easy to understand for me. I've done some small debugging right now. If I add the following message statements into the helper (right after the find_library call) I got output to variables that should be empty. > message( STATUS "NGSPICE_INCLUDE_DIR=${NGSPICE_INCLUDE_DIR}") > message( STATUS "NGSPICE_LIBRARY=${NGSPICE_LIBRARY}") > message( STATUS "CMAKE_LIBRARY_ARCHITECTURE=${CMAKE_LIBRARY_ARCHITECTURE}") > message( STATUS "NGSPICE_LIBRARY_PATH=${NGSPICE_LIBRARY_PATH}") > message( STATUS "NGSPICE_ROOT_DIR=${NGSPICE_ROOT_DIR}") > message( STATUS "CMAKE_LIBRARY_PATH=${CMAKE_LIBRARY_PATH}") > $ cmake .. -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_SCRIPTING_WXPYTHON=ON > -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SPICE=ON -DKICAD_USE_OCE=ON > -DCMAKE_INSTALL_PREFIX=/home/carsten/tmp/kicad > ... > -- NGSPICE_INCLUDE_DIR=/usr/share/ngspice/include > -- NGSPICE_LIBRARY=/usr/lib/libngspice.so > -- CMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu > -- NGSPICE_LIBRARY_PATH= > -- NGSPICE_ROOT_DIR= > -- CMAKE_LIBRARY_PATH= > -- Check for installed Python Interpreter -- found > $ LANG= ls /usr/share/ngspice/include > ls: cannot access '/usr/share/ngspice/include': No such file or directory > $ LANG= ls /usr/lib/libngspice.so > ls: cannot access '/usr/lib/libngspice.so': No such file or directory I'm quite sure there is something not correct in the cmake helper for ngspice. -- Regards Carsten Schoenert ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Improving behavior and logic of Findngspice.cmake
Hi Carsten, have you tried specifying -DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu when calling cmake in the build script? Relevant documentation here, in roughly the 2nd paragraph: https://cmake.org/cmake/help/v3.0/command/find_library.html Thanks, Dan W On Tuesday, 16 January 2018 19:23:25 GMT Carsten Schoenert wrote: > Hi, > > as written some days ago I'm working currently on packaging of ngspice > for Debian main. > For this I must follow the Debian (packaging) policy [1]. This requires > the installation of shared libraries into /usr/lib/triplet due policy > 9.1.1.4 (see [2]). triplet means here the architecture there the > installation is happen. For i386 this would be the folder > '/usr/lib/i386-linux-gnu' and for amd64 '/usr/lib/x86_64-linux-gnu' and > so on. > > The build of the KiCad development tree is currently not working with > those folders as the cmake snippet for libngspice does not care about > this constellation. > > I would provide a patch here to fix this but I have no real clue about > CMake! So I requesting some help here, could please someone with more > knowledge than me improve the cmake helper for libngspice to search also > in such folders for the library? The header is already found in the new > (default) installation folder /user/include. > So far I've could find relevant and depended information the path there > to look while searching for libngsice.so would be > /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} for CMake. > > And, if someone is going to dig into this could also be added the search > and pickup of a pkg-config file for libngspice? I will work on adding a > pkg-config file for libngspice in the next week so it would be great if > the intelligence for using of a pkg-config file could be added in the > same go. > > I think something like this logic should be sufficient and not collide > with the current content. > > if (pkg-config found) > do read the pkg-config > else > search for the devel files manually > fi > > Thanks! > > I gladly help to test modifications of Findngspice.cmake. > > [1] https://www.debian.org/doc/debian-policy/ > [2] https://www.debian.org/doc/debian-policy/#file-system-structure signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Improving behavior and logic of Findngspice.cmake
Hi, as written some days ago I'm working currently on packaging of ngspice for Debian main. For this I must follow the Debian (packaging) policy [1]. This requires the installation of shared libraries into /usr/lib/triplet due policy 9.1.1.4 (see [2]). triplet means here the architecture there the installation is happen. For i386 this would be the folder '/usr/lib/i386-linux-gnu' and for amd64 '/usr/lib/x86_64-linux-gnu' and so on. The build of the KiCad development tree is currently not working with those folders as the cmake snippet for libngspice does not care about this constellation. I would provide a patch here to fix this but I have no real clue about CMake! So I requesting some help here, could please someone with more knowledge than me improve the cmake helper for libngspice to search also in such folders for the library? The header is already found in the new (default) installation folder /user/include. So far I've could find relevant and depended information the path there to look while searching for libngsice.so would be /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} for CMake. And, if someone is going to dig into this could also be added the search and pickup of a pkg-config file for libngspice? I will work on adding a pkg-config file for libngspice in the next week so it would be great if the intelligence for using of a pkg-config file could be added in the same go. I think something like this logic should be sufficient and not collide with the current content. if (pkg-config found) do read the pkg-config else search for the devel files manually fi Thanks! I gladly help to test modifications of Findngspice.cmake. [1] https://www.debian.org/doc/debian-policy/ [2] https://www.debian.org/doc/debian-policy/#file-system-structure -- Regards Carsten Schoenert ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp