I just pushed the fix to remove LIB_ID::Test which was deprecated so
everything should be fixed now.
On 2/7/20 2:05 PM, Simon Richter wrote:
> Hi,
>
> On 07.02.20 19:58, Jon Evans wrote:
>
>> In lib_id.h, LIB_ID::Test() is declared inside "#if defined(DEBUG)"
>
>> But in lib_id.cpp,
On 2020-02-07 12:41 p.m., jp charras wrote:
Attached, my latest version of file format documents.
Thanks for the PDF files. They appear to be the same docs I downloaded in
February of 2017. I looked at a few of the files once again. They have no
indication of when they were produced, what is
Hi,
On 07.02.20 19:58, Jon Evans wrote:
> In lib_id.h, LIB_ID::Test() is declared inside "#if defined(DEBUG)"
> But in lib_id.cpp, LIB_ID::Test() will never be implemented because it
> is wrapped in:
> #if 0 && defined(DEBUG)
lol, so this worked only because -DDEBUG was never defined for SWIG
In lib_id.h, LIB_ID::Test() is declared inside "#if defined(DEBUG)"
But in lib_id.cpp, LIB_ID::Test() will never be implemented because it is
wrapped in:
#if 0 && defined(DEBUG)
I have no idea the history of this (git blames you, Wayne), but this seems
like it would create linker errors for
I tried commenting out line 404 in pcbnew/CMakeList:
#-I${WXPYTHON_SWIG_DIR}
but that didn't help either.
On 2/7/20 1:42 PM, Simon Richter wrote:
> Hi,
>
> On 07.02.20 19:31, Jon Evans wrote:
>
>> Good find! I think we should remove that line
>> (pcbnew/CMakeLists.txt:403) since it's
Hi,
On 07.02.20 19:31, Jon Evans wrote:
> Good find! I think we should remove that line
> (pcbnew/CMakeLists.txt:403) since it's not used.
> I guess we have just been clobbering KICAD_CONFIG_DIR for swig and it
> just didn't matter.
Yes, that should be done for the sake of cleanup.
The other
Good find! I think we should remove that line (pcbnew/CMakeLists.txt:403)
since it's not used.
I guess we have just been clobbering KICAD_CONFIG_DIR for swig and it just
didn't matter.
On Fri, Feb 7, 2020 at 1:29 PM Simon Richter
wrote:
> Hi,
>
> On 07.02.20 19:19, Simon Richter wrote:
>
> >
Hi,
On 07.02.20 19:19, Simon Richter wrote:
> This. The COMPILE_DEFINITIONS property is applied to CC and CXX
> invocations, not to the SWIG command line.
Spoke too soon. Those are actually applied. What is happening is that
swig is invoked as
/usr/bin/swig3.0 -python -c++ -outdir
In pcbnew/CMakeLists.txt line 406 there is:
if( DEBUG )
set( SWIG_FLAGS ${SWIG_FLAGS} -DDEBUG )
endif()
Maybe this isn't working anymore?
Right below it is something that looks to pull in COMPILE_DEFINITIONS from
the parent, which I thought would include DEBUG as well.
On Fri, Feb 7,
No luck. Adding those lines didn't resolve the issue for me.
On 2/7/20 12:40 PM, Jon Evans wrote:
> Wayne, can you revert the changes on lines 343-347 and add back -DDEBUG
> to those four locations, keeping the added part around line 173 of the
> CMakeLists.txt?
>
> If that fixes it, it tells
Hi,
On 07.02.20 18:54, Jon Evans wrote:
> Avenues of investigation I can think of:
> 1) This is swig-related, and somehow it's not picking up the -DDEBUG
> flag under the new way of defining it
This. The COMPILE_DEFINITIONS property is applied to CC and CXX
invocations, not to the SWIG command
I am seeing -DDEBUG doing a verbose build but I haven't watched every
single file build so maybe something is getting stepped on in the qa
build. Is it possible that one of the qa CMakeList.txt files is setting
compiler flags in without including the flags inherited from previous
definitions?
On
I have scripting turned off on my OSX machine so I can't test this until
later today.
I'm happy for someone to just revert that commit until we figure it out, or
partially revert it as per my previous email if that is enough to fix it.
@Simon not sure if you have any clues what could cause this.
Yes, I also see the issue (on OSX).
> On 7 Feb 2020, at 17:40, Jon Evans wrote:
>
> Wayne, can you revert the changes on lines 343-347 and add back -DDEBUG to
> those four locations, keeping the added part around line 173 of the
> CMakeLists.txt?
>
> If that fixes it, it tells us that for
Wayne, can you revert the changes on lines 343-347 and add back -DDEBUG to
those four locations, keeping the added part around line 173 of the
CMakeLists.txt?
If that fixes it, it tells us that for some reason the set_property call is
not resulting in the -DDEBUG making it into the makefiles on
On 2020-02-07 3:41 a.m., Eeli Kaikkonen wrote:
Wayne gave this link recently:
https://bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/view/head:/doc/help/file_formats/file_formats.pdf
But it leads to a broken download
I found the actual PDF file at that site. It may not be the version
At the moment I only have access to my Mac, and can confirm that -DDEBUG
does get added to my build file although it doesn't show as a variable in
CMakeCache.txt
I use ninja so I see it in the build lines of the build.ninja file
Can you confirm if your makefile has -DDEBUG set or not for the
Neither `make rebuild_cache` or a clean build fixed the issue. Attached
is the CMakeCache.txt file.
On 2/7/20 11:50 AM, Jon Evans wrote:
> LIB_ID::Test is hidden behind a DEBUG ifdef check. So, it seems like in
> your configuration the CMake change is not setting DEBUG anymore.
> Are you able
LIB_ID::Test is hidden behind a DEBUG ifdef check. So, it seems like in
your configuration the CMake change is not setting DEBUG anymore.
Are you able to inspect your CMakeCache.txt to shed some light on this?
On Fri, Feb 7, 2020 at 11:46 AM Wayne Stambaugh
wrote:
> I'm running into this
I'm running into this build failure on my Debian Bullseye box as of the
latest commits to the master branch:
/usr/bin/ld:
../../pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/pcbnew_wrap.cxx.o: in
function `_wrap_LIB_ID_Test':
Wayne gave this link recently:
https://bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/view/head:/doc/help/file_formats/file_formats.pdf
But it leads to a broken download - the file seems to be there because it's
previewed as plain text, but can't be downloaded properly.
I suggest moving
21 matches
Mail list logo
