kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

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