On 01/23/2013 12:43 PM, Brian Sidebotham wrote:
> I used to think these problems were solely down to mingw32-make, however from
> the other
> cmake problem, perhaps some of them are not.
>
> I've not seen this problem before, this is the first time I've come across
> it, but it is
> repeatable.
At first glance it seems there are multiple threads building the same target.
There is no mutual exclusion on this target to thread assignment.
The target being built "twice, simultaneously" is attached, and I find it in
file.
build/CMakeFiles/pcbnew.dir/build.make
on linux. Please check on
Hi Dick,
Sorry I should have included the log file excerpt:
mingw32-make[2]: *** [pcbnew/CMakeFiles/pcbnew.dir/pcbframe.cpp.obj] Error 1
In file included from
C:/kicad-winbuilder-dev/kicad-winbuilder/src/kicad/pcbnew/./specctra.h:36:0,
from
C:\kicad-winbuilder-dev\kicad-winbuilde
On 01/23/2013 12:43 PM, Brian Sidebotham wrote:
> I used to think these problems were solely down to mingw32-make, however from
> the other
> cmake problem, perhaps some of them are not.
>
> I've not seen this problem before, this is the first time I've come across
> it, but it is
> repeatable. -
Le 23/01/2013 18:16, Dick Hollenbeck a écrit :
On 01/23/2013 10:38 AM, Dick Hollenbeck wrote:
On 01/23/2013 10:21 AM, Dick Hollenbeck wrote:
On 01/23/2013 10:12 AM, Miguel Angel Ajo Pelayo wrote:
Dick if you could take a look at it I'd thank you very very much,you're our
cmake expert
:-).
I used to think these problems were solely down to mingw32-make, however
from the other cmake problem, perhaps some of them are not.
I've not seen this problem before, this is the first time I've come across
it, but it is repeatable. -j6 produces the attached output, and no a single
process result
LOL - I can only hope that I don't recite cmake lines or KiCad code on the
day! ;)
Thanks for that fix Dick.
However, there is a new problem with parallel builds (I use -j6) on MinGW
(at least using mingw32-make) with new builds when generating
specctra_lexer.h. I'll start a new topic with what i
Hahaha, thanks dick, yes it really sounds like Brian's problem in mingw. :-)
That changes were introduced by me trying to fix compilation in OSX, I will
review them later, and check what was I trying to do, or what did I
drink thanks for cleaning my mess in there.
2013/1/23 Dick Hollenbeck
El 23/01/13 16:56, jp charras escribió:
> ...
>>> Therefore (like in paste block) time stamps of new items should be
>>> checked and updated (and perhaps the references).
>>> I am thinking a lot of users will use such a feature to create multiple
>>> instances of a basic sheet, as an alternative to
On 01/23/2013 10:38 AM, Dick Hollenbeck wrote:
> On 01/23/2013 10:21 AM, Dick Hollenbeck wrote:
>> On 01/23/2013 10:12 AM, Miguel Angel Ajo Pelayo wrote:
>>> Dick if you could take a look at it I'd thank you very very much,you're our
>>> cmake expert
>>> :-).
>>>
>>> I haven't ever seen the failu
I just checked--today's builds are queued up and will be starting within an
hour, so any pushed revs from this morning should be pulled in.
Adam Wolf
Wayne and Layne, LLC
On Wed, Jan 23, 2013 at 10:38 AM, Dick Hollenbeck wrote:
> On 01/23/2013 10:21 AM, Dick Hollenbeck wrote:
> > On 01/23/2013
On 01/23/2013 10:21 AM, Dick Hollenbeck wrote:
> On 01/23/2013 10:12 AM, Miguel Angel Ajo Pelayo wrote:
>> Dick if you could take a look at it I'd thank you very very much,you're our
>> cmake expert
>> :-).
>>
>> I haven't ever seen the failure, but will try this night with different -j
>> value
On 01/23/2013 10:12 AM, Miguel Angel Ajo Pelayo wrote:
> Dick if you could take a look at it I'd thank you very very much,you're our
> cmake expert
> :-).
>
> I haven't ever seen the failure, but will try this night with different -j
> values (I
> usually do it with 5).
OK, I think I know what'
On 01/23/2013 10:09 AM, Dick Hollenbeck wrote:
> On 01/23/2013 08:02 AM, Miguel Angel Ajo Pelayo wrote:
>> Somebody told me about this, I think it was Brian.
>>
>> I think we must have introduced some change to the cmake scripts that change
>> the build
>> order in this case, or my cmake scripts w
Dick if you could take a look at it I'd thank you very very much,you're our
cmake expert :-).
I haven't ever seen the failure, but will try this night with different -j
values (I usually do it with 5).
2013/1/23 Dick Hollenbeck
> On 01/23/2013 08:02 AM, Miguel Angel Ajo Pelayo wrote:
> > Som
On 01/23/2013 08:02 AM, Miguel Angel Ajo Pelayo wrote:
> Somebody told me about this, I think it was Brian.
>
> I think we must have introduced some change to the cmake scripts that change
> the build
> order in this case, or my cmake scripts were not good... It was my first
> cmake script.
>
> T
Le 23/01/2013 13:55, Jacobo Aragunde Pérez a écrit :
El 22/01/13 09:47, jp charras escribió:
Le 21/01/2013 10:46, Jacobo Aragunde Pérez a écrit :
...
I've checked the approach used in Pcbnew. After an import, the current
document name changes, so it doesn't overwrite the existing one unless
you
Somebody told me about this, I think it was Brian.
I think we must have introduced some change to the cmake scripts that
change the build order in this case, or my cmake scripts were not good...
It was my first cmake script.
This step should happen after swig executed already (and not before), el
El 22/01/13 09:47, jp charras escribió:
> Le 21/01/2013 10:46, Jacobo Aragunde Pérez a écrit :
>> ...
>> I've checked the approach used in Pcbnew. After an import, the current
>> document name changes, so it doesn't overwrite the existing one unless
>> you specifically want to.
>>
>> I think I will
I just noticed that the ppa builds are failing with this error:
[ 79%] Fixing swig_import_helper in Kicad scripting
Traceback (most recent call last):
File
"/build/buildd/kicad-0.201301222033+3918~13~raring1/kicad/pcbnew/../scripting/fixswigimports.py",
line 26, in
f = open(filename,"rb")
20 matches
Mail list logo
