kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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.
>