hauptmech,
I tested this on windows and it doesn't seem to break anything that I
can see so I merged it. Thank you for your contribution to KiCad.
Cheers,
Wayne
On 2/25/2018 8:49 PM, hauptmech wrote:
>
> Attached
>
> On 26/02/18 11:15, Wayne Stambaugh wrote:
>> hauptmech,
>>
>> Would you ple
Attached
On 26/02/18 11:15, Wayne Stambaugh wrote:
hauptmech,
Would you please attach this change as a committed patch when you get
a chance? I want to test this on windows and linux and maybe we can
get one of our macos devs to test it there as well. I would like to
work out any packagin
We can test it for macOS as well. I'm spending some time on it every day
at this point to get it ready for v5, so now is the perfect time :)
On Feb 25, 2018 4:16 PM, "Wayne Stambaugh" wrote:
> hauptmech,
>
> Would you please attach this change as a committed patch when you get a
> chance? I wa
hauptmech,
Would you please attach this change as a committed patch when you get a
chance? I want to test this on windows and linux and maybe we can get
one of our macos devs to test it there as well. I would like to work
out any packaging issues as soon as possible to give our package devs
I don't have enough understanding of all the platforms to suggest a full
patch. However the following works for me on linux (two targets, but shared
object files so there should be no significant change in compile time)
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..78
What do you mean by a second target? Keep in mind that we don't want to
recompile everything twice just because of the kiface libraries. If you can
create a target which is dependent on the pcbnew stand-alone app and
which used the object files to create a shared library, that would be good.
I can'
I took a look at what approaches might work to fix this.
I looked at removing the RPATH manually, in keeping with manual file
manipulation approach used by the authors of this section of the CMake
file. Shell tools to do this don't appear to be universal and it's not
using the CMake way. So I
I've confirmed that there is a wrong RPATH in the install. The issue is
in pcbnew/CMakeFiles.txt#if( KICAD_SCRIPTING_MODULES ).
Rather than using the CMake install target script, _pcbnew.so is getting
copied manually and then installed as a file.
On 25/02/18 10:37, Carsten Schoenert wrote:
H
The RUNPATH should be stripped by the linker, if it isn't then there is a
problem in our build system. I created the various dynamic plugins and
the scenegraph library and made sure that the RUNPATH is removed;
it is of value primarily to developers and in general is nothing but a
headache when dep
On 25/02/18 10:37, Carsten Schoenert wrote:
the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have*no* RUNPATH.
I'm not understanding this thread 100% so apologies if this misses the
point.
RPATH is set by defau
Hello Wayne,
Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
> Carsten,
>
> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
>> Hi,
>>
>> I guess it's not intended that the library / shared object _pcbnew.so
>> build in pcbnew/ set up a RPATH based on the build directory?
>
> This is the kicad pyt
Carsten,
On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
Hi,
I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?
This is the kicad python scripting shared object which should get
installed in the correct python
Hi,
I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?
> root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so |
> grep build
> libkicad_3dsg.so.2.0.0 =>
> /build/kicad-5.0.0~rc0+dfsg1/deb
13 matches
Mail list logo