Am 2019-01-31 12:24, schrieb jp charras:
Le 31/01/2019 à 18:21, John Beard a écrit :
Hi JP,
On Thu, Jan 31, 2019 at 4:55 PM jp charras
wrote:
Perhaps this:
target_include_directories( pcbnew_kiface_objects PRIVATE
$
)
Unfortunately, does not work.
Is it the same error?
Cheers,
Jo
On 1/31/2019 1:15 PM, Simon Richter wrote:
> Hi,
>
> On 31.01.19 18:11, Simon Richter wrote:
>
>>> I would prefer that we create a base units object and then derived
>>> application level units objects as needed. These objects would be
>>> small, compile quickly, and could be included in the com
Hi,
On 31.01.19 18:11, Simon Richter wrote:
>> I would prefer that we create a base units object and then derived
>> application level units objects as needed. These objects would be
>> small, compile quickly, and could be included in the common library so
>> they are available everywhere. Usin
Le 31/01/2019 à 18:21, John Beard a écrit :
> Hi JP,
>
> On Thu, Jan 31, 2019 at 4:55 PM jp charras wrote:
>>
>>> Perhaps this:
>>>
>>> target_include_directories( pcbnew_kiface_objects PRIVATE
>>>$
>>> )
>>
>> Unfortunately, does not work.
>
> Is it the same error?
>
> Cheers,
>
> John
>
Le 31/01/2019 à 17:48, John Beard a écrit :
> The second set of patches I just sent seems to work on the Ubuntu
> docker image with CMake 3.5.1.
>
> Cheers,
>
> John
Hi John,
After cleaning the build directory and reappling your second set, the
build works.
I tested it on msys2 with cmake 3.7,
Hi Wayne,
On 31.01.19 17:49, Wayne Stambaugh wrote:
> I would prefer that we create a base units object and then derived
> application level units objects as needed. These objects would be
> small, compile quickly, and could be included in the common library so
> they are available everywhere.
Hi JP,
On Thu, Jan 31, 2019 at 4:55 PM jp charras wrote:
>
> > Perhaps this:
> >
> > target_include_directories( pcbnew_kiface_objects PRIVATE
> >$
> > )
>
> Unfortunately, does not work.
Is it the same error?
Cheers,
John
___
Mailing list: http
On 1/31/2019 11:17 AM, Simon Richter wrote:
> Hi,
>
> On 31.01.19 16:11, jp charras wrote:
>
>> "CMake Error at pcbnew/CMakeLists.txt:645 (target_link_libraries):
>> Object library target "pcbnew_kiface_objects" may not link to anything."
>
> By the way, why are we even linking pcbnew twice? T
Simon,
On 1/31/2019 10:49 AM, Simon Richter wrote:
> Hi,
>
> On 31.01.19 16:01, John Beard wrote:
>
>> I'm not really sure. I suppose it depends on the benefits it brings (and
>> in future with shared common libs, perhaps it won't matter as much?)
>
> I doubt it makes much of a difference — the
Le 31/01/2019 à 17:27, John Beard a écrit :
> Hmm,
>
> Perhaps this:
>
> target_include_directories( pcbnew_kiface_objects PRIVATE
>$
> )
>
> This gives the desired effect of providing the transitive include
> dirs, but doesn't require the recent CMake ability to link OBJECT
> libraries.
Un
On 1/31/2019 11:27 AM, jp charras wrote:
> Le 31/01/2019 à 16:52, jp charras a écrit :
>> Le 31/01/2019 à 16:29, Wayne Stambaugh a écrit :
>>> JP,
>>>
>>> On 1/31/2019 10:11 AM, jp charras wrote:
Le 31/01/2019 à 15:40, John Beard a écrit :
> Hi,
>
> Two patches for building these l
The second set of patches I just sent seems to work on the Ubuntu
docker image with CMake 3.5.1.
Cheers,
John
On Thu, Jan 31, 2019 at 4:42 PM Wayne Stambaugh wrote:
>
> On 1/31/2019 11:27 AM, jp charras wrote:
> > Le 31/01/2019 à 16:52, jp charras a écrit :
> >> Le 31/01/2019 à 16:29, Wayne Sta
Le 31/01/2019 à 16:52, jp charras a écrit :
> Le 31/01/2019 à 16:29, Wayne Stambaugh a écrit :
>> JP,
>>
>> On 1/31/2019 10:11 AM, jp charras wrote:
>>> Le 31/01/2019 à 15:40, John Beard a écrit :
Hi,
Two patches for building these libs:
1) Make bitmaps a "Proper" library.
Hi,
On 31.01.19 16:11, jp charras wrote:
> "CMake Error at pcbnew/CMakeLists.txt:645 (target_link_libraries):
> Object library target "pcbnew_kiface_objects" may not link to anything."
By the way, why are we even linking pcbnew twice? The python module and
the kiface are bitwise identical on m
Le 31/01/2019 à 16:29, Wayne Stambaugh a écrit :
> JP,
>
> On 1/31/2019 10:11 AM, jp charras wrote:
>> Le 31/01/2019 à 15:40, John Beard a écrit :
>>> Hi,
>>>
>>> Two patches for building these libs:
>>>
>>> 1) Make bitmaps a "Proper" library. By splitting it off like this, the
>>> includes for ea
Hi,
On 31.01.19 16:29, Wayne Stambaugh wrote:
> I didn't have any problem creating a 32 bit build using msys2. It maybe
> your CMake version. I'm using CMake 3.12.4. I also did a clean build
> so that could the issue. This change works pretty well so I hope it's
> not a CMake version issue.
Hi,
On 31.01.19 16:01, John Beard wrote:
> I'm not really sure. I suppose it depends on the benefits it brings (and
> in future with shared common libs, perhaps it won't matter as much?)
I doubt it makes much of a difference — the biggest hot spots in compile
time are:
- waiting for pcbnew_wra
JP,
On 1/31/2019 10:11 AM, jp charras wrote:
> Le 31/01/2019 à 15:40, John Beard a écrit :
>> Hi,
>>
>> Two patches for building these libs:
>>
>> 1) Make bitmaps a "Proper" library. By splitting it off like this, the
>> includes for each of the hundreds of XPM cpp files do not need to suck
>> in
Le 31/01/2019 à 15:40, John Beard a écrit :
> Hi,
>
> Two patches for building these libs:
>
> 1) Make bitmaps a "Proper" library. By splitting it off like this, the
> includes for each of the hundreds of XPM cpp files do not need to suck
> in WX headers. This speeds compilation by something like
Hi Tom,
I'm not really sure. I suppose it depends on the benefits it brings (and in
future with shared common libs, perhaps it won't matter as much?)
Doesn't separate KiFace imply a separate unit test and utility tools too, which
would be a bit of extra overhead? Unless you can still combine?
On 31/01/2019 15:40, John Beard wrote:
> Hi,
>
> Two patches for building these libs:
>
> 1) Make bitmaps a "Proper" library. By splitting it off like this, the
> includes for each of the hundreds of XPM cpp files do not need to suck
> in WX headers. This speeds compilation by something like 10x
21 matches
Mail list logo
