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
