Re: [Kicad-developers] build failure

2021-03-10 Thread Jonatan Liljedahl
On Wed, Mar 10, 2021 at 2:34 PM Jon Evans  wrote:
>
> > As I said earlier, it links fine for me now. It might have been some
> > combination of installing CommandLineTools via xcode-select and
> > uninstalling and reinstalling OCC.
>
> Well, I did those things too and was still having the same problem :(
>
> I guess I can try blowing up homebrew and the tools/sdk and starting from 
> scratch.

I have OSX_SYSROOT as follows:

CMAKE_OSX_SYSROOT:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk

I attach my full CMakeCache.txt in case it helps.

Before, it was set to MacOSX10.15.sdk but recent Xcode does not ship
with such an SDK, and I tried working around it by symlinking
MacOSX10.15.sdk->MacOSX11.0.sdk. I think it all just made a mess, so I
removed the symlink, installed CommandLineTools via xcode-select,
reinstalled opencascade, and started with a clean build directory, and
then it worked.

-- 
/Jonatan
http://kymatica.com
# This is the CMakeCache file.
# For build in directory: /Users/lijon/Coding/kicad/build/master
# It was generated by CMake: /Applications/CMake.app/Contents/bin/cmake
# You can edit this file to change values found and used by cmake.
# If you do not want to change any of the values, simply exit the editor.
# If you do want to change a value, simply edit, save, and exit the editor.
# The syntax for the file is as follows:
# KEY:TYPE=VALUE
# KEY is the name of a variable in the cache.
# TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
# VALUE is the current value for the KEY.


# EXTERNAL cache entries


//Dependencies for the target
3d-viewer_LIB_DEPENDS:STATIC=general;gal;general;kimath;general;-L/Users/lijon/Coding/wxWidgets/wxwidgets-dest/lib;general;-framework
 IOKit;general;-framework Carbon;general;-framework Cocoa;general;-framework 
AudioToolbox;general;-framework System;general;-framework 
OpenGL;general;-lwx_osx_cocoau_gl-3.1;general;-lwx_osx_cocoau-3.1;general;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/OpenGL.framework;general;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/System/Library/Frameworks/OpenGL.framework;general;kicad_3dsg;

//In debug build: create smaller binaries.
BUILD_SMALL_DEBUG_FILES:BOOL=OFF

//Build the testing tree.
BUILD_TESTING:BOOL=OFF

//Path to a program.
BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND

//The directory containing a CMake configuration file for Boost.
Boost_DIR:PATH=Boost_DIR-NOTFOUND

//Boost filesystem library (debug)
Boost_FILESYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/local/lib/libboost_filesystem-mt.dylib

//Boost filesystem library (release)
Boost_FILESYSTEM_LIBRARY_RELEASE:FILEPATH=/usr/local/lib/libboost_filesystem-mt.dylib

//Path to a file.
Boost_INCLUDE_DIR:PATH=/usr/local/include

//Boost library directory DEBUG
Boost_LIBRARY_DIR_DEBUG:PATH=/usr/local/lib

//Boost library directory RELEASE
Boost_LIBRARY_DIR_RELEASE:PATH=/usr/local/lib

//Boost system library (debug)
Boost_SYSTEM_LIBRARY_DEBUG:FILEPATH=/usr/local/lib/libboost_system-mt.dylib

//Boost system library (release)
Boost_SYSTEM_LIBRARY_RELEASE:FILEPATH=/usr/local/lib/libboost_system-mt.dylib

//Boost unit_test_framework library (debug)
Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG:FILEPATH=/usr/local/lib/libboost_unit_test_framework-mt.dylib

//Boost unit_test_framework library (release)
Boost_UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE:FILEPATH=/usr/local/lib/libboost_unit_test_framework-mt.dylib

//Path to a file.
CAIRO_INCLUDE_DIR:PATH=/usr/local/include/cairo

//Path to a library.
CAIRO_LIBRARY:FILEPATH=/usr/local/Cellar/cairo/1.16.0_5/lib/libcairo.dylib

//Path to a program.
CMAKE_AR:FILEPATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar

//Set to either "Release" or "Debug"
CMAKE_BUILD_TYPE:STRING=Debug

//Enable/Disable color output during build.
CMAKE_COLOR_MAKEFILE:BOOL=ON

//CXX compiler
CMAKE_CXX_COMPILER:FILEPATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++

//Flags used by the CXX compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the CXX compiler during DEBUG builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG

//C compiler
CMAKE_C_COMPILER:FILEPATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

//Flags used by the C compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the C compiler during DEBUG builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by 

Re: [Kicad-developers] build failure

2021-03-10 Thread Jon Evans
> As I said earlier, it links fine for me now. It might have been some
> combination of installing CommandLineTools via xcode-select and
> uninstalling and reinstalling OCC.

Well, I did those things too and was still having the same problem :(

I guess I can try blowing up homebrew and the tools/sdk and starting from
scratch.

-Jon

On Wed, Mar 10, 2021 at 7:59 AM Jonatan Liljedahl 
wrote:

> Hi,
>
> As I said earlier, it links fine for me now. It might have been some
> combination of installing CommandLineTools via xcode-select and
> uninstalling and reinstalling OCC. I did not force a 10.14 bottle.
>
> However, 'make install' still fails for me so I'm running kicad from
> the build dir (which works mostly). I think it might be the same issue
> as https://gitlab.com/kicad/code/kicad/-/issues/3718
>
> Would be great if we could find a fix for this..
>
> -- fixup_bundle
> --
>  app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
> --
>  
> libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
> --   dirs=' /usr/local/opt/opencascade/lib'
> --   ignoreItems=''
> -- fixup_bundle: preparing...
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> CMake Error at
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
> (message):
>   otool -l failed: 1
>
>
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
>   error: '@loader_path/libTKVCAF.7.dylib': No such file or directory
>
> Call Stack (most recent call first):
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
> (get_item_rpaths)
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
> (set_bundle_key_values)
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
> (get_bundle_keys)
>   kicad/cmake_install.cmake:101 (fixup_bundle)
>   cmake_install.cmake:67 (include)
>
> On Wed, Mar 10, 2021 at 3:48 AM Adam Wolf 
> wrote:
> >
> > I haven't seen that.  I can take a look at a bigger build log if you
> want.
> >
> > To be clear for others, I'm not advocating carrying around a 10.14
> > bottle of opencascade; this is troubleshooting in progress :)
> >
> > Adam
> >
> > On Tue, Mar 9, 2021 at 7:02 PM Jon Evans  wrote:
> > >
> > > Hi Jonatan,
> > >
> > > I hit the exact same issue (I'm also on 10.15), and after chatting
> with Adam about it, decided to try using the 10.14 bottle manually:
> > >
> > > Download
> https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz
> > >
> > > Install with:
> > >
> > > brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
> > > brew link --overwrite opencascade
> > >
> > > After this, I am able to get past the opencascade link errors.
> > >
> > > I do have another error after this, which I haven't figured out yet:
> > >
> > > make[6]: *** No rule to make target
> `/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by
> `kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.
> > >
> > > @Adam or anyone else, have you seen this before?
> > >
> > > -Jon
> > >
> > > On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl 
> wrote:
> > >>
> > >> On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf <
> adamw...@feelslikeburning.com> wrote:
> > >> >
> > >> > It is certainly possible that Homebrew is distributing bottles that
> > >> > are linked a little weird, and you'd be getting the MacOS 10.14
> > >> > reference from that.  We've had this happen before.
> > >>
> > >> Yes, I think this was the case with my OCE install, OCEConfig.cmake
> > >> referenced 10.14. After unbrewing OCE, I tried to brew install it
> > >> again but only got a 404. However, after that I 

Re: [Kicad-developers] build failure

2021-03-10 Thread Jonatan Liljedahl
Hi,

As I said earlier, it links fine for me now. It might have been some
combination of installing CommandLineTools via xcode-select and
uninstalling and reinstalling OCC. I did not force a 10.14 bottle.

However, 'make install' still fails for me so I'm running kicad from
the build dir (which works mostly). I think it might be the same issue
as https://gitlab.com/kicad/code/kicad/-/issues/3718

Would be great if we could find a fix for this..

-- fixup_bundle
--   
app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
--   
libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
--   dirs=' /usr/local/opt/opencascade/lib'
--   ignoreItems=''
-- fixup_bundle: preparing...
-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

CMake Error at 
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
(message):
  otool -l failed: 1


  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
  error: '@loader_path/libTKVCAF.7.dylib': No such file or directory

Call Stack (most recent call first):
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
(get_item_rpaths)
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
(set_bundle_key_values)
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
(get_bundle_keys)
  kicad/cmake_install.cmake:101 (fixup_bundle)
  cmake_install.cmake:67 (include)

On Wed, Mar 10, 2021 at 3:48 AM Adam Wolf  wrote:
>
> I haven't seen that.  I can take a look at a bigger build log if you want.
>
> To be clear for others, I'm not advocating carrying around a 10.14
> bottle of opencascade; this is troubleshooting in progress :)
>
> Adam
>
> On Tue, Mar 9, 2021 at 7:02 PM Jon Evans  wrote:
> >
> > Hi Jonatan,
> >
> > I hit the exact same issue (I'm also on 10.15), and after chatting with 
> > Adam about it, decided to try using the 10.14 bottle manually:
> >
> > Download 
> > https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz
> >
> > Install with:
> >
> > brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
> > brew link --overwrite opencascade
> >
> > After this, I am able to get past the opencascade link errors.
> >
> > I do have another error after this, which I haven't figured out yet:
> >
> > make[6]: *** No rule to make target 
> > `/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by 
> > `kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.
> >
> > @Adam or anyone else, have you seen this before?
> >
> > -Jon
> >
> > On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl  wrote:
> >>
> >> On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf  
> >> wrote:
> >> >
> >> > It is certainly possible that Homebrew is distributing bottles that
> >> > are linked a little weird, and you'd be getting the MacOS 10.14
> >> > reference from that.  We've had this happen before.
> >>
> >> Yes, I think this was the case with my OCE install, OCEConfig.cmake
> >> referenced 10.14. After unbrewing OCE, I tried to brew install it
> >> again but only got a 404. However, after that I reinstalled OCC and it
> >> built fine so maybe OCE and OCC was in conflict or something.
> >>
> >> > Regarding the libTKVCAF error, it looks like something's not quite
> >> > right between the library and the fixup_bundle call.
> >> >
> >> > Does libTKVCAF.7.dylib exist on your system?
> >>
> >> Yes, that and all other OCC libs exist in
> >> /usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
> >> /usr/local/lib (by homebrew).
> >>
> >> So I assume the problem here is that it's not finding all these libs
> >> at runtime? How can I check if this is actually the issue 

Re: [Kicad-developers] build failure

2021-03-09 Thread Adam Wolf
I haven't seen that.  I can take a look at a bigger build log if you want.

To be clear for others, I'm not advocating carrying around a 10.14
bottle of opencascade; this is troubleshooting in progress :)

Adam

On Tue, Mar 9, 2021 at 7:02 PM Jon Evans  wrote:
>
> Hi Jonatan,
>
> I hit the exact same issue (I'm also on 10.15), and after chatting with Adam 
> about it, decided to try using the 10.14 bottle manually:
>
> Download 
> https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz
>
> Install with:
>
> brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
> brew link --overwrite opencascade
>
> After this, I am able to get past the opencascade link errors.
>
> I do have another error after this, which I haven't figured out yet:
>
> make[6]: *** No rule to make target 
> `/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by 
> `kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.
>
> @Adam or anyone else, have you seen this before?
>
> -Jon
>
> On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl  wrote:
>>
>> On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf  
>> wrote:
>> >
>> > It is certainly possible that Homebrew is distributing bottles that
>> > are linked a little weird, and you'd be getting the MacOS 10.14
>> > reference from that.  We've had this happen before.
>>
>> Yes, I think this was the case with my OCE install, OCEConfig.cmake
>> referenced 10.14. After unbrewing OCE, I tried to brew install it
>> again but only got a 404. However, after that I reinstalled OCC and it
>> built fine so maybe OCE and OCC was in conflict or something.
>>
>> > Regarding the libTKVCAF error, it looks like something's not quite
>> > right between the library and the fixup_bundle call.
>> >
>> > Does libTKVCAF.7.dylib exist on your system?
>>
>> Yes, that and all other OCC libs exist in
>> /usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
>> /usr/local/lib (by homebrew).
>>
>> So I assume the problem here is that it's not finding all these libs
>> at runtime? How can I check if this is actually the issue here?
>>
>> During "make install" I get all these warnings:
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCAF.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKCAF.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKV3d.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKV3d.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKLCAF.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKLCAF.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCDF.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKCDF.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKBO.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKBO.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKPrim.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKPrim.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKService.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKService.7.dylib'
>>
>>   possible problems:
>> need more directories?
>> need to use InstallRequiredSystemLibraries?
>> run in install tree instead of build tree?
>>
>> -- warning: embedded item does not exist
>> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKMesh.7.dylib'
>> --
>> warning: cannot resolve item '@loader_path/libTKMesh.7.dylib'
>>
>>   possible problems:
>>  

Re: [Kicad-developers] build failure

2021-03-09 Thread Jon Evans
Hi Jonatan,

I hit the exact same issue (I'm also on 10.15), and after chatting with
Adam about it, decided to try using the 10.14 bottle manually:

Download
https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz

Install with:

brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
brew link --overwrite opencascade

After this, I am able to get past the opencascade link errors.

I do have another error after this, which I haven't figured out yet:

make[6]: *** No rule to make target
`/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by
`kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.

@Adam or anyone else, have you seen this before?

-Jon

On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl  wrote:

> On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf 
> wrote:
> >
> > It is certainly possible that Homebrew is distributing bottles that
> > are linked a little weird, and you'd be getting the MacOS 10.14
> > reference from that.  We've had this happen before.
>
> Yes, I think this was the case with my OCE install, OCEConfig.cmake
> referenced 10.14. After unbrewing OCE, I tried to brew install it
> again but only got a 404. However, after that I reinstalled OCC and it
> built fine so maybe OCE and OCC was in conflict or something.
>
> > Regarding the libTKVCAF error, it looks like something's not quite
> > right between the library and the fixup_bundle call.
> >
> > Does libTKVCAF.7.dylib exist on your system?
>
> Yes, that and all other OCC libs exist in
> /usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
> /usr/local/lib (by homebrew).
>
> So I assume the problem here is that it's not finding all these libs
> at runtime? How can I check if this is actually the issue here?
>
> During "make install" I get all these warnings:
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKV3d.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKV3d.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKLCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKLCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCDF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKCDF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKBO.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKBO.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKPrim.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKPrim.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKService.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKService.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKMesh.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKMesh.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKShHealing.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKShHealing.7.dylib'
>
>   possible problems:
> need more directories?
> 

Re: [Kicad-developers] build failure

2021-03-06 Thread Jonatan Liljedahl
On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf  wrote:
>
> It is certainly possible that Homebrew is distributing bottles that
> are linked a little weird, and you'd be getting the MacOS 10.14
> reference from that.  We've had this happen before.

Yes, I think this was the case with my OCE install, OCEConfig.cmake
referenced 10.14. After unbrewing OCE, I tried to brew install it
again but only got a 404. However, after that I reinstalled OCC and it
built fine so maybe OCE and OCC was in conflict or something.

> Regarding the libTKVCAF error, it looks like something's not quite
> right between the library and the fixup_bundle call.
>
> Does libTKVCAF.7.dylib exist on your system?

Yes, that and all other OCC libs exist in
/usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
/usr/local/lib (by homebrew).

So I assume the problem here is that it's not finding all these libs
at runtime? How can I check if this is actually the issue here?

During "make install" I get all these warnings:

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCAF.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKCAF.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKV3d.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKV3d.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKLCAF.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKLCAF.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCDF.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKCDF.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKBO.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKBO.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKPrim.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKPrim.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKService.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKService.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKMesh.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKMesh.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKShHealing.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKShHealing.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKHLR.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKHLR.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKTopAlgo.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKTopAlgo.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKGeomAlgo.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKGeomAlgo.7.dylib'

  possible 

Re: [Kicad-developers] build failure

2021-03-05 Thread Adam Wolf
It is certainly possible that Homebrew is distributing bottles that
are linked a little weird, and you'd be getting the MacOS 10.14
reference from that.  We've had this happen before.

Regarding the libTKVCAF error, it looks like something's not quite
right between the library and the fixup_bundle call.

Does libTKVCAF.7.dylib exist on your system?

On Fri, Mar 5, 2021 at 1:40 PM Nick Østergaard  wrote:
>
> Maybe try the kicad-mac-buidler just to verify your environment works?
> It should use the same brew stuff as you manually use.
>
> https://gitlab.com/kicad/packaging/kicad-mac-builder/
>
> On Fri, 5 Mar 2021 at 17:44, Jonatan Liljedahl  wrote:
> >
> > I tried "make install" in case something wasn't in the right place,
> > but now that fails (which used to work fine):
> >
> > -- fixup_bundle
> > --   
> > app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
> > --   
> > libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
> > --   dirs=' /usr/local/lib'
> > --   ignoreItems=''
> > -- fixup_bundle: preparing...
> > -- warning: embedded item does not exist
> > '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
> > --
> > warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'
> >
> >   possible problems:
> > need more directories?
> > need to use InstallRequiredSystemLibraries?
> > run in install tree instead of build tree?
> >
> > CMake Error at 
> > /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
> > (message):
> >   otool -l failed: 1
> >
> >
> >   
> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
> >   error: '@loader_path/libTKVCAF.7.dylib': No such file or directory
> >
> > Call Stack (most recent call first):
> >   
> > /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
> > (get_item_rpaths)
> >   
> > /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
> > (set_bundle_key_values)
> >   
> > /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
> > (get_bundle_keys)
> >   kicad/cmake_install.cmake:101 (fixup_bundle)
> >   cmake_install.cmake:67 (include)
> >
> >
> > make: *** [install] Error 1
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] build failure

2021-03-05 Thread Nick Østergaard
Maybe try the kicad-mac-buidler just to verify your environment works?
It should use the same brew stuff as you manually use.

https://gitlab.com/kicad/packaging/kicad-mac-builder/

On Fri, 5 Mar 2021 at 17:44, Jonatan Liljedahl  wrote:
>
> I tried "make install" in case something wasn't in the right place,
> but now that fails (which used to work fine):
>
> -- fixup_bundle
> --   
> app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
> --   
> libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
> --   dirs=' /usr/local/lib'
> --   ignoreItems=''
> -- fixup_bundle: preparing...
> -- warning: embedded item does not exist
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
> (message):
>   otool -l failed: 1
>
>
>   
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
>   error: '@loader_path/libTKVCAF.7.dylib': No such file or directory
>
> Call Stack (most recent call first):
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
> (get_item_rpaths)
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
> (set_bundle_key_values)
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
> (get_bundle_keys)
>   kicad/cmake_install.cmake:101 (fixup_bundle)
>   cmake_install.cmake:67 (include)
>
>
> make: *** [install] Error 1

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] build failure

2021-03-05 Thread Jonatan Liljedahl
I tried "make install" in case something wasn't in the right place,
but now that fails (which used to work fine):

-- fixup_bundle
--   
app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
--   
libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
--   dirs=' /usr/local/lib'
--   ignoreItems=''
-- fixup_bundle: preparing...
-- warning: embedded item does not exist
'/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
-- 
warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'

  possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?

CMake Error at 
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
(message):
  otool -l failed: 1


  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
  error: '@loader_path/libTKVCAF.7.dylib': No such file or directory

Call Stack (most recent call first):
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
(get_item_rpaths)
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
(set_bundle_key_values)
  
/Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
(get_bundle_keys)
  kicad/cmake_install.cmake:101 (fixup_bundle)
  cmake_install.cmake:67 (include)


make: *** [install] Error 1

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] build failure

2021-03-05 Thread Jonatan Liljedahl
Ok,
I finally made it build with OCC, after uninstalling and reinstalling
OCC with homebrew. Not sure what happened..
However, now there are *no* 3D models showing up.
I noticed that there's a new KICAD6_3DMODEL_DIR path, which defaults
to "/usr/local/3dmodels/" (where I have no 3d models).
Is this new variable used instead of KISYS3DMOD?


On Fri, Mar 5, 2021 at 1:08 PM Nick Østergaard  wrote:
>
> @Jonatan Liljedahl  Please share your cmake commandss
>
> On Fri, 5 Mar 2021 at 12:42, Jeff Young  wrote:
> >
> > I never managed to get this to work (but my kung fu with build systems is 
> > notoriously weak).
> >
> > Anyway, my current build flags are:
> >
> > -DCMAKE_C_COMPILER=clang
> > -DCMAKE_CXX_COMPILER=clang++
> > -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14
> > -DwxWidgets_CONFIG_EXECUTABLE=/Users/jeff/kicad_dev/wxWidgets/wx-bin/bin/wx-config
> > -DKICAD_STDLIB_LIGHT_DEBUG=OFF
> > -DKICAD_SANITIZE=0
> > -DKICAD_SCRIPTING=OFF
> > -DKICAD_SCRIPTING_MODULES=OFF
> > -DKICAD_SCRIPTING_WXPYTHON=OFF
> > -DKICAD_USE_OCE=OFF
> > -DMAINTAIN_PNGS=OFF
> > -DCMAKE_INSTALL_PREFIX=./bin
> > -DCMAKE_BUILD_TYPE=Debug
> > -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
> >
> > I think the breakage in 3D model rendering is elsewhere.
> >
> > Cheers,
> > Jeff.
> >
> >
> > On 5 Mar 2021, at 11:28, Jonatan Liljedahl  wrote:
> >
> > I've tried with a fresh build dir, still getting this:
> > Undefined symbols for architecture x86_64:
> >  "Standard_Type::Register(char const*, char const*, unsigned long,
> > opencascade::handle const&)", referenced from:
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  opencascade::type_instance::get() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  "Quantity_Color::valuesOf(Quantity_NameOfColor,
> > Quantity_TypeOfColor)", referenced from:
> >  PCBMODEL::transferModel(opencascade::handle&,
> > opencascade::handle&, TRIPLET) in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  "BRepLib_Command::~BRepLib_Command()", referenced from:
> >  BRepLib_MakeShape::~BRepLib_MakeShape() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  "BRepAlgoAPI_Algo::Shape()", referenced from:
> >  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
> >  "Geom_BezierCurve::Geom_BezierCurve(NCollection_Array1
> > const&)", referenced from:
> >  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
> > DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
> >  "Standard_Failure::~Standard_Failure()", referenced from:
> >  Standard_ConstructionError::~Standard_ConstructionError() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  Standard_ConstructionError::~Standard_ConstructionError() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  Standard_OutOfMemory::~Standard_OutOfMemory() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  Standard_OutOfRange::~Standard_OutOfRange() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  Standard_OutOfRange::~Standard_OutOfRange() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  "XCAFDoc_ShapeTool::AddComponent(TDF_Label const&, TDF_Label const&,
> > TopLoc_Location const&)", referenced from:
> >  PCBMODEL::AddComponent(std::__1::basic_string > std::__1::char_traits, std::__1::allocator > const&,
> > std::__1::basic_string,
> > std::__1::allocator > const&, bool, DOUBLET, double, TRIPLET,
> > TRIPLET, TRIPLET) in libkicad2step_lib.a(oce_utils.cpp.o)
> >  "XCAFDoc_ShapeTool::UpdateAssemblies()", referenced from:
> >  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
> >  "NCollection_BaseMap::Destroy(void (*)(NCollection_ListNode*,
> > opencascade::handle&), bool)", referenced
> > from:
> >  BRepTools_Modifier::~BRepTools_Modifier() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_Map > TopTools_ShapeMapHasher>::~NCollection_Map() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_DataMap > BRepTools_Modifier::NewSurfaceInfo,
> > TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_DataMap > BRepTools_Modifier::NewCurveInfo,
> > TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_DataMap > TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_Map > TopTools_ShapeMapHasher>::~NCollection_Map() in
> > libkicad2step_lib.a(oce_utils.cpp.o)
> >  NCollection_DataMap > BRepTools_Modifier::NewSurfaceInfo,
> > TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> > 

Re: [Kicad-developers] build failure

2021-03-05 Thread Nick Østergaard
@Jonatan Liljedahl  Please share your cmake commandss

On Fri, 5 Mar 2021 at 12:42, Jeff Young  wrote:
>
> I never managed to get this to work (but my kung fu with build systems is 
> notoriously weak).
>
> Anyway, my current build flags are:
>
> -DCMAKE_C_COMPILER=clang
> -DCMAKE_CXX_COMPILER=clang++
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14
> -DwxWidgets_CONFIG_EXECUTABLE=/Users/jeff/kicad_dev/wxWidgets/wx-bin/bin/wx-config
> -DKICAD_STDLIB_LIGHT_DEBUG=OFF
> -DKICAD_SANITIZE=0
> -DKICAD_SCRIPTING=OFF
> -DKICAD_SCRIPTING_MODULES=OFF
> -DKICAD_SCRIPTING_WXPYTHON=OFF
> -DKICAD_USE_OCE=OFF
> -DMAINTAIN_PNGS=OFF
> -DCMAKE_INSTALL_PREFIX=./bin
> -DCMAKE_BUILD_TYPE=Debug
> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
>
> I think the breakage in 3D model rendering is elsewhere.
>
> Cheers,
> Jeff.
>
>
> On 5 Mar 2021, at 11:28, Jonatan Liljedahl  wrote:
>
> I've tried with a fresh build dir, still getting this:
> Undefined symbols for architecture x86_64:
>  "Standard_Type::Register(char const*, char const*, unsigned long,
> opencascade::handle const&)", referenced from:
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::type_instance::get() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "Quantity_Color::valuesOf(Quantity_NameOfColor,
> Quantity_TypeOfColor)", referenced from:
>  PCBMODEL::transferModel(opencascade::handle&,
> opencascade::handle&, TRIPLET) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "BRepLib_Command::~BRepLib_Command()", referenced from:
>  BRepLib_MakeShape::~BRepLib_MakeShape() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "BRepAlgoAPI_Algo::Shape()", referenced from:
>  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
>  "Geom_BezierCurve::Geom_BezierCurve(NCollection_Array1
> const&)", referenced from:
>  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
> DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
>  "Standard_Failure::~Standard_Failure()", referenced from:
>  Standard_ConstructionError::~Standard_ConstructionError() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  Standard_ConstructionError::~Standard_ConstructionError() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  Standard_OutOfMemory::~Standard_OutOfMemory() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  Standard_OutOfRange::~Standard_OutOfRange() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  Standard_OutOfRange::~Standard_OutOfRange() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "XCAFDoc_ShapeTool::AddComponent(TDF_Label const&, TDF_Label const&,
> TopLoc_Location const&)", referenced from:
>  PCBMODEL::AddComponent(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&,
> std::__1::basic_string,
> std::__1::allocator > const&, bool, DOUBLET, double, TRIPLET,
> TRIPLET, TRIPLET) in libkicad2step_lib.a(oce_utils.cpp.o)
>  "XCAFDoc_ShapeTool::UpdateAssemblies()", referenced from:
>  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
>  "NCollection_BaseMap::Destroy(void (*)(NCollection_ListNode*,
> opencascade::handle&), bool)", referenced
> from:
>  BRepTools_Modifier::~BRepTools_Modifier() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_Map TopTools_ShapeMapHasher>::~NCollection_Map() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_DataMap BRepTools_Modifier::NewSurfaceInfo,
> TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_DataMap BRepTools_Modifier::NewCurveInfo,
> TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_DataMap TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_Map TopTools_ShapeMapHasher>::~NCollection_Map() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_DataMap BRepTools_Modifier::NewSurfaceInfo,
> TopTools_ShapeMapHasher>::~NCollection_DataMap() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  ...
>  "NCollection_BaseList::PClear(void (*)(NCollection_ListNode*,
> opencascade::handle&))", referenced from:
>  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_List::~NCollection_List() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  BRepBuilderAPI_MakeShape::~BRepBuilderAPI_MakeShape() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_List::Assign(NCollection_List
> const&) in libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_DataMap NCollection_List,
> TopTools_ShapeMapHasher>::DataMapNode::~DataMapNode() in
> 

Re: [Kicad-developers] build failure

2021-03-05 Thread Jonatan Liljedahl
I've tried with a fresh build dir, still getting this:
Undefined symbols for architecture x86_64:
  "Standard_Type::Register(char const*, char const*, unsigned long,
opencascade::handle const&)", referenced from:
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "Quantity_Color::valuesOf(Quantity_NameOfColor,
Quantity_TypeOfColor)", referenced from:
  PCBMODEL::transferModel(opencascade::handle&,
opencascade::handle&, TRIPLET) in
libkicad2step_lib.a(oce_utils.cpp.o)
  "BRepLib_Command::~BRepLib_Command()", referenced from:
  BRepLib_MakeShape::~BRepLib_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "BRepAlgoAPI_Algo::Shape()", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  "Geom_BezierCurve::Geom_BezierCurve(NCollection_Array1
const&)", referenced from:
  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
  "Standard_Failure::~Standard_Failure()", referenced from:
  Standard_ConstructionError::~Standard_ConstructionError() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_ConstructionError::~Standard_ConstructionError() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfMemory::~Standard_OutOfMemory() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfRange::~Standard_OutOfRange() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfRange::~Standard_OutOfRange() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "XCAFDoc_ShapeTool::AddComponent(TDF_Label const&, TDF_Label const&,
TopLoc_Location const&)", referenced from:
  PCBMODEL::AddComponent(std::__1::basic_string, std::__1::allocator > const&,
std::__1::basic_string,
std::__1::allocator > const&, bool, DOUBLET, double, TRIPLET,
TRIPLET, TRIPLET) in libkicad2step_lib.a(oce_utils.cpp.o)
  "XCAFDoc_ShapeTool::UpdateAssemblies()", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  "NCollection_BaseMap::Destroy(void (*)(NCollection_ListNode*,
opencascade::handle&), bool)", referenced
from:
  BRepTools_Modifier::~BRepTools_Modifier() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_Map::~NCollection_Map() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_Map::~NCollection_Map() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  ...
  "NCollection_BaseList::PClear(void (*)(NCollection_ListNode*,
opencascade::handle&))", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::~NCollection_List() in
libkicad2step_lib.a(oce_utils.cpp.o)
  BRepBuilderAPI_MakeShape::~BRepBuilderAPI_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::Assign(NCollection_List
const&) in libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap,
TopTools_ShapeMapHasher>::DataMapNode::~DataMapNode() in
libkicad2step_lib.a(oce_utils.cpp.o)
  BRepLib_MakeShape::~BRepLib_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::~NCollection_List() in
libkicad2step_lib.a(oce_utils.cpp.o)
  ...
  "Standard_OutOfMemory::Standard_OutOfMemory(char const*)", referenced from:
  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
  "IGESCAFControl_Reader::Transfer(opencascade::handle&,
Message_ProgressRange const&)", referenced from:
  PCBMODEL::readIGES(opencascade::handle&, char
const*) in libkicad2step_lib.a(oce_utils.cpp.o)
  "STEPCAFControl_Reader::Transfer(opencascade::handle&,
Message_ProgressRange const&)", referenced from:
  PCBMODEL::readSTEP(opencascade::handle&, char
const*) in libkicad2step_lib.a(oce_utils.cpp.o)
  "STEPCAFControl_Reader::~STEPCAFControl_Reader()", referenced from:
  PCBMODEL::readSTEP(opencascade::handle&, char
const*) in libkicad2step_lib.a(oce_utils.cpp.o)
  "STEPCAFControl_Writer::Transfer(opencascade::handle
const&, STEPControl_StepModelType, char const*, Message_ProgressRange
const&)", referenced from:
  PCBMODEL::WriteSTEP(wxString const&) in
libkicad2step_lib.a(oce_utils.cpp.o)
  "BRepBuilderAPI_Command::~BRepBuilderAPI_Command()", referenced from:
  

Re: [Kicad-developers] build failure

2021-03-05 Thread Nick Østergaard
You need to make sure you have a clean buid dir and try yo explicitly
disable oce and enable occt on your cmake configure line.

fre. 5. mar. 2021 11.48 skrev Jonatan Liljedahl :

> Ok, I'm now trying to build against OCE instead, as I'm sure that used
> to work before.
> I managed to have CMake find my homebrew installed OCE by setting
> OCE_DIR, however it fails here:
>
> make[2]: *** No rule to make target
>
> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework',
> needed by `kicad/KiCad.app/Contents/MacOS/kicad2step'.  Stop.
>
> Because I don't have MacOSX10.14.sdk, but 10.15. The weird thing is
> that I have set CMake build variables to the correct path:
>
> CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.15
>
> CMAKE_OSX_SYSROOT:PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
>
> But even then, kicad2step still has 10.14:
>
>
> utils/kicad2step/CMakeFiles/kicad2step.dir/build.make:kicad/KiCad.app/Contents/MacOS/kicad2step:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework
>
> Removing utils/kicad2step/CMakeFiles (and plugins/3d/oce/CMakeFiles),
> a recursive grep in my build directory tells me that there's NO
> mention of "MacOSX10.14" anywhere. But after I've run cmake, it shows
> up again in the above mentioned places!
>
> So where is this "MacOSX10.14" reference coming from?
>
> lijon@lijon-mbp kicad % grep -R --include CMakeLists.txt 10.14 .
>
> ...show nothing, so it must come outside the kicad source tree.
> Any ideas?
>
> Cheers
> /Jonatan
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] build failure

2021-03-05 Thread Jonatan Liljedahl
Ok, I'm now trying to build against OCE instead, as I'm sure that used
to work before.
I managed to have CMake find my homebrew installed OCE by setting
OCE_DIR, however it fails here:

make[2]: *** No rule to make target
`/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework',
needed by `kicad/KiCad.app/Contents/MacOS/kicad2step'.  Stop.

Because I don't have MacOSX10.14.sdk, but 10.15. The weird thing is
that I have set CMake build variables to the correct path:

CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.15
CMAKE_OSX_SYSROOT:PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk

But even then, kicad2step still has 10.14:

utils/kicad2step/CMakeFiles/kicad2step.dir/build.make:kicad/KiCad.app/Contents/MacOS/kicad2step:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework

Removing utils/kicad2step/CMakeFiles (and plugins/3d/oce/CMakeFiles),
a recursive grep in my build directory tells me that there's NO
mention of "MacOSX10.14" anywhere. But after I've run cmake, it shows
up again in the above mentioned places!

So where is this "MacOSX10.14" reference coming from?

lijon@lijon-mbp kicad % grep -R --include CMakeLists.txt 10.14 .

...show nothing, so it must come outside the kicad source tree.
Any ideas?

Cheers
/Jonatan

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] build failure

2021-03-05 Thread Jonatan Liljedahl
I'm having trouble building on mac after enabling OCC.
I had both OCC and OCE disabled and I assume that's why 3D viewer
didn't show STEP models any more.
I installed OCC 7.5.0 using homebrew 'opencascade' formula.
Is it possible to disable just kicad2step?

[ 30%] Linking CXX static library libkicad2step_lib.a
[ 30%] Built target kicad2step_lib
[ 30%] Building CXX object
3d-viewer/3d_cache/sg/CMakeFiles/kicad_3dsg.dir/ifsg_faceset.cpp.o
[ 30%] Building CXX object
libs/kimath/CMakeFiles/kimath.dir/src/geometry/shape_poly_set.cpp.o
[ 30%] Building CXX object
utils/kicad2step/CMakeFiles/kicad2step.dir/kicad2step.cpp.o
[ 30%] Building CXX object
3d-viewer/3d_cache/sg/CMakeFiles/kicad_3dsg.dir/ifsg_normals.cpp.o
[ 30%] Building CXX object
3d-viewer/3d_cache/sg/CMakeFiles/kicad_3dsg.dir/ifsg_shape.cpp.o
[ 30%] Building CXX object
libs/kimath/CMakeFiles/kimath.dir/src/geometry/shape_rect.cpp.o
[ 30%] Linking CXX executable ../../kicad/KiCad.app/Contents/MacOS/kicad2step
Undefined symbols for architecture x86_64:
  "Standard_Type::Register(char const*, char const*, unsigned long,
opencascade::handle const&)", referenced from:
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  opencascade::type_instance::get() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "Quantity_Color::valuesOf(Quantity_NameOfColor,
Quantity_TypeOfColor)", referenced from:
  PCBMODEL::transferModel(opencascade::handle&,
opencascade::handle&, TRIPLET) in
libkicad2step_lib.a(oce_utils.cpp.o)
  "BRepLib_Command::~BRepLib_Command()", referenced from:
  BRepLib_MakeShape::~BRepLib_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "BRepAlgoAPI_Algo::Shape()", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  "Geom_BezierCurve::Geom_BezierCurve(NCollection_Array1
const&)", referenced from:
  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
  "Standard_Failure::~Standard_Failure()", referenced from:
  Standard_ConstructionError::~Standard_ConstructionError() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_ConstructionError::~Standard_ConstructionError() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfMemory::~Standard_OutOfMemory() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfRange::~Standard_OutOfRange() in
libkicad2step_lib.a(oce_utils.cpp.o)
  Standard_OutOfRange::~Standard_OutOfRange() in
libkicad2step_lib.a(oce_utils.cpp.o)
  "XCAFDoc_ShapeTool::AddComponent(TDF_Label const&, TDF_Label const&,
TopLoc_Location const&)", referenced from:
  PCBMODEL::AddComponent(std::__1::basic_string, std::__1::allocator > const&,
std::__1::basic_string,
std::__1::allocator > const&, bool, DOUBLET, double, TRIPLET,
TRIPLET, TRIPLET) in libkicad2step_lib.a(oce_utils.cpp.o)
  "XCAFDoc_ShapeTool::UpdateAssemblies()", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  "NCollection_BaseMap::Destroy(void (*)(NCollection_ListNode*,
opencascade::handle&), bool)", referenced
from:
  BRepTools_Modifier::~BRepTools_Modifier() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_Map::~NCollection_Map() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_Map::~NCollection_Map() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap::~NCollection_DataMap() in
libkicad2step_lib.a(oce_utils.cpp.o)
  ...
  "NCollection_BaseList::PClear(void (*)(NCollection_ListNode*,
opencascade::handle&))", referenced from:
  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::~NCollection_List() in
libkicad2step_lib.a(oce_utils.cpp.o)
  BRepBuilderAPI_MakeShape::~BRepBuilderAPI_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::Assign(NCollection_List
const&) in libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_DataMap,
TopTools_ShapeMapHasher>::DataMapNode::~DataMapNode() in
libkicad2step_lib.a(oce_utils.cpp.o)
  BRepLib_MakeShape::~BRepLib_MakeShape() in
libkicad2step_lib.a(oce_utils.cpp.o)
  NCollection_List::~NCollection_List() in
libkicad2step_lib.a(oce_utils.cpp.o)
  ...
  "Standard_OutOfMemory::Standard_OutOfMemory(char const*)", referenced from:
  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
  

Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 8:28 PM, Steven A. Falco wrote:

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.


Ok, I've updated the packaging script and merged that into gitlab.  The next 
nightly should build correctly for rawhide.

I'll tackle the downstream script tomorrow.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
Good luck.

I've been putting off updating the Audacity spec file that I am maintainer
on because of the cmake macro changes. But in my case I have to rewrite the
entire spec to use cmake since they removed their autotools-based build
system and instead introduced a broken cmake build system now - and they
did this in a patch release... that is not going to be fun to switch to.

-Ian

On Mon, Jul 20, 2020 at 11:08 PM Steven A. Falco 
wrote:

> On 7/20/20 6:01 PM, Ian McInerney wrote:
> > You should be able to switch the macros:
> > %cmake -> %cmake
> > %make_build -> %cmake_build
> > %make_install -> %cmake_install
> >
> > Then the builds and install will automatically use the proper out of
> tree directory. See the change proposal page for more details:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
> .
>
> Thanks, Ian.  I'll give that a try later.  But if I have to iterate a few
> times to get everything right, it could take some time.
>
> Steve
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
There should be no differences with where things get installed to - and if
there are then our "install" targets are incorrect and should be fixed
upstream. The changes to the cmake macros are simply for the build system.

-Ian

On Mon, Jul 20, 2020 at 11:04 PM Steven A. Falco 
wrote:

> On 7/20/20 5:37 PM, Seth Hillbrand wrote:
> > Hi Steve-
> >
> > This looks like a build setup issue, not in our CMake code.  We can
> build out of tree (in fact, we really prefer it) right now.  From the log,
> the broken command is
> > /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
> >
> > You can modify this in your .spec.template file.
>
> I understand that, and I use out-of-tree builds for most of my local KiCAD
> builds.  But that is not how the nightlies work.  They are built on the
> Copr website, and they use the normal RPM build mechanism.
>
> You are correct that there is nothing wrong with our CMake code, and we
> can fix our build setup.  But it is more than just compiling the source.
> There are lots of other components that get built, and the location of the
> files that get rolled into the package will also change a bit.  So the
> changes will take some time to sort out, especially given how long it takes
> to test a build.  Hence the proposal of the workaround.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install

Then the builds and install will automatically use the proper out of tree 
directory. See the change proposal page for more details: 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration.


Thanks, Ian.  I'll give that a try later.  But if I have to iterate a few times 
to get everything right, it could take some time.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 5:37 PM, Seth Hillbrand wrote:

Hi Steve-

This looks like a build setup issue, not in our CMake code.  We can build out 
of tree (in fact, we really prefer it) right now.  From the log, the broken 
command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
-DKICAD_SCRIPTING_PYTHON3=ON -DKICAD_SCRIPTING_WXPYTHON=ON 
-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON -DKICAD_SCRIPTING_ACTION_MENU=ON 
-DKICAD_USE_OCC=ON -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON -DKICAD_VERSION_EXTRA=r19086-6d8fb94d 
-DCMAKE_BUILD_TYPE=Debug .

You can modify this in your .spec.template file.


I understand that, and I use out-of-tree builds for most of my local KiCAD 
builds.  But that is not how the nightlies work.  They are built on the Copr 
website, and they use the normal RPM build mechanism.

You are correct that there is nothing wrong with our CMake code, and we can fix 
our build setup.  But it is more than just compiling the source.  There are 
lots of other components that get built, and the location of the files that get 
rolled into the package will also change a bit.  So the changes will take some 
time to sort out, especially given how long it takes to test a build.  Hence 
the proposal of the workaround.

Steve
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install

Then the builds and install will automatically use the proper out of tree
directory. See the change proposal page for more details:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
.

-Ian

On Mon, Jul 20, 2020 at 10:29 PM Steven A. Falco 
wrote:

> Fedora recently made a change to their cmake macros, to force packages to
> build "out of tree".  The developers responsible for this change plan to go
> through and fix up the thousand or so packages that may break as a result,
> so they should eventually fix the official downstream KiCAD package.
>
> However, they will not be able to fix up third-party packages, one of
> which is our nightly builds.
>
> The attached email shows that KiCAD does indeed fail to build for Fedora
> rawhide now.  The right thing to do is to modify the kicad.spec.template
> file to accommodate the new cmake macros, but as a temporary workaround, we
> can add a line to force the old behavior:
>
> %global __cmake_in_source_build 1
>
> I've tried that, and it does let KiCAD build as before.
>
> I don't know exactly how the developers plan to fix up the broken
> packages, so we can either add the workaround, wait to see what they do,
> then change the nightlies to match (and remove the workaround), OR we can
> make our own changes, which may result in the spec files diverging.
>
> If the lead KiCAD devs wish, I can add the workaround - I can do that
> quickly.  Attempting to sort out a proper fix would naturally take longer.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 5:34 PM, Nick Østergaard wrote:

What does this mean if I want to test this locally?

Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...


To test locally, I use our kicad-fedora-builder/builder.sh script with the -m 
(mock) option:

./builder.sh -m fedora-rawhide-x86_64

For that to work, you have to have set up for mock, by installing it and adding 
your uid to the mock group.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
Re: that.. https://www.spinics.net/lists/fedora-devel/msg274669.html

Quote from an Igor:

I'm confused by the proposal, it is named "CMake to do out-of-source builds"

but the macros seems to do the opposite?

On Rawhide (local repo):

%__cmake \
-S "%{_vpath_srcdir}" \
-B "%{__cmake_builddir}" \

__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
__cmake_in_source_build1

Looks like __cmake_builddir is defined as "." so the build will happen
in source?


On Mon, 20 Jul 2020 at 23:45, Nick Østergaard  wrote:
>
> I am not sure I misunderstand the terminology here, but "cmake -S . -B
> foo -Dnickersej" looks "in tree" to me.
>
> On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
> >
> > Hi Steve-
> >
> > This looks like a build setup issue, not in our CMake code.  We can
> > build out of tree (in fact, we really prefer it) right now.  From the
> > log, the broken command is
> > /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> > -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> > -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> > -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> > -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> > -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> > -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> > -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
> >
> > You can modify this in your .spec.template file.
> >
> > Best-
> > Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > On 2020-07-20 14:28, Steven A. Falco wrote:
> > > Fedora recently made a change to their cmake macros, to force packages
> > > to build "out of tree".  The developers responsible for this change
> > > plan to go through and fix up the thousand or so packages that may
> > > break as a result, so they should eventually fix the official
> > > downstream KiCAD package.
> > >
> > > However, they will not be able to fix up third-party packages, one of
> > > which is our nightly builds.
> > >
> > > The attached email shows that KiCAD does indeed fail to build for
> > > Fedora rawhide now.  The right thing to do is to modify the
> > > kicad.spec.template file to accommodate the new cmake macros, but as a
> > > temporary workaround, we can add a line to force the old behavior:
> > >
> > > %global __cmake_in_source_build 1
> > >
> > > I've tried that, and it does let KiCAD build as before.
> > >
> > > I don't know exactly how the developers plan to fix up the broken
> > > packages, so we can either add the workaround, wait to see what they
> > > do, then change the nightlies to match (and remove the workaround), OR
> > > we can make our own changes, which may result in the spec files
> > > diverging.
> > >
> > > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > > quickly.  Attempting to sort out a proper fix would naturally take
> > > longer.
> > >
> > >   Steve
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
I am not sure I misunderstand the terminology here, but "cmake -S . -B
foo -Dnickersej" looks "in tree" to me.

On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
>
> Hi Steve-
>
> This looks like a build setup issue, not in our CMake code.  We can
> build out of tree (in fact, we really prefer it) right now.  From the
> log, the broken command is
> /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
>
> You can modify this in your .spec.template file.
>
> Best-
> Seth
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> On 2020-07-20 14:28, Steven A. Falco wrote:
> > Fedora recently made a change to their cmake macros, to force packages
> > to build "out of tree".  The developers responsible for this change
> > plan to go through and fix up the thousand or so packages that may
> > break as a result, so they should eventually fix the official
> > downstream KiCAD package.
> >
> > However, they will not be able to fix up third-party packages, one of
> > which is our nightly builds.
> >
> > The attached email shows that KiCAD does indeed fail to build for
> > Fedora rawhide now.  The right thing to do is to modify the
> > kicad.spec.template file to accommodate the new cmake macros, but as a
> > temporary workaround, we can add a line to force the old behavior:
> >
> > %global __cmake_in_source_build 1
> >
> > I've tried that, and it does let KiCAD build as before.
> >
> > I don't know exactly how the developers plan to fix up the broken
> > packages, so we can either add the workaround, wait to see what they
> > do, then change the nightlies to match (and remove the workaround), OR
> > we can make our own changes, which may result in the spec files
> > diverging.
> >
> > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > quickly.  Attempting to sort out a proper fix would naturally take
> > longer.
> >
> >   Steve
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Seth Hillbrand

Hi Steve-

This looks like a build setup issue, not in our CMake code.  We can 
build out of tree (in fact, we really prefer it) right now.  From the 
log, the broken command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON 
-DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON 
-DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON 
-DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON 
-DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .


You can modify this in your .spec.template file.

Best-
Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

On 2020-07-20 14:28, Steven A. Falco wrote:

Fedora recently made a change to their cmake macros, to force packages
to build "out of tree".  The developers responsible for this change
plan to go through and fix up the thousand or so packages that may
break as a result, so they should eventually fix the official
downstream KiCAD package.

However, they will not be able to fix up third-party packages, one of
which is our nightly builds.

The attached email shows that KiCAD does indeed fail to build for
Fedora rawhide now.  The right thing to do is to modify the
kicad.spec.template file to accommodate the new cmake macros, but as a
temporary workaround, we can add a line to force the old behavior:

%global __cmake_in_source_build 1

I've tried that, and it does let KiCAD build as before.

I don't know exactly how the developers plan to fix up the broken
packages, so we can either add the workaround, wait to see what they
do, then change the nightlies to match (and remove the workaround), OR
we can make our own changes, which may result in the spec files
diverging.

If the lead KiCAD devs wish, I can add the workaround - I can do that
quickly.  Attempting to sort out a proper fix would naturally take
longer.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
What does this mean if I want to test this locally?

Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...


On Mon, 20 Jul 2020 at 23:28, Steven A. Falco  wrote:
>
> Fedora recently made a change to their cmake macros, to force packages to 
> build "out of tree".  The developers responsible for this change plan to go 
> through and fix up the thousand or so packages that may break as a result, so 
> they should eventually fix the official downstream KiCAD package.
>
> However, they will not be able to fix up third-party packages, one of which 
> is our nightly builds.
>
> The attached email shows that KiCAD does indeed fail to build for Fedora 
> rawhide now.  The right thing to do is to modify the kicad.spec.template file 
> to accommodate the new cmake macros, but as a temporary workaround, we can 
> add a line to force the old behavior:
>
> %global __cmake_in_source_build 1
>
> I've tried that, and it does let KiCAD build as before.
>
> I don't know exactly how the developers plan to fix up the broken packages, 
> so we can either add the workaround, wait to see what they do, then change 
> the nightlies to match (and remove the workaround), OR we can make our own 
> changes, which may result in the spec files diverging.
>
> If the lead KiCAD devs wish, I can add the workaround - I can do that 
> quickly.  Attempting to sort out a proper fix would naturally take longer.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

Fedora recently made a change to their cmake macros, to force packages to build "out 
of tree".  The developers responsible for this change plan to go through and fix up 
the thousand or so packages that may break as a result, so they should eventually fix the 
official downstream KiCAD package.

However, they will not be able to fix up third-party packages, one of which is 
our nightly builds.

The attached email shows that KiCAD does indeed fail to build for Fedora 
rawhide now.  The right thing to do is to modify the kicad.spec.template file 
to accommodate the new cmake macros, but as a temporary workaround, we can add 
a line to force the old behavior:

%global __cmake_in_source_build 1

I've tried that, and it does let KiCAD build as before.

I don't know exactly how the developers plan to fix up the broken packages, so 
we can either add the workaround, wait to see what they do, then change the 
nightlies to match (and remove the workaround), OR we can make our own changes, 
which may result in the spec files diverging.

If the lead KiCAD devs wish, I can add the workaround - I can do that quickly.  
Attempting to sort out a proper fix would naturally take longer.

Steve


--- Begin Message ---
Notification time stamped 2020-07-20 17:31:25 UTC

Package:  kicad-100:r19086-6d8fb94d.fc33
COPR: @kicad/kicad
Built by: nickoe
Status:   failed
ID:   01565774

Logs:
  Build: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/build.log.gz
  Root:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/root.log.gz
  Copr:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/build-01565774.log
  Mockchain: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/mockchain.log.gz
Results: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/
Repodata:
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/repodata/

https://copr.fedoraproject.org/coprs/g/kicad/kicad/build/1565774/

--
You received this message due to your preference settings at 
https://apps.fedoraproject.org/notifications/stevenfalco.id.fedoraproject.org/email/60697--- End Message ---
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure - probably a race generating template_fieldnames_lexer.h

2019-06-04 Thread Steven A. Falco
On 6/4/19 12:41 PM, Seth Hillbrand wrote:
> On 2019-06-04 11:07, Steven A. Falco wrote:
>> I think I just hit the builder race condition that was discussed a few
>> days ago.  I've attached a copy of template_fieldnames_lexer.h.  At
>> line 184 there is an #endif, and then part of the file appears to
>> repeat.  Thus, I wind up with an unmatched #endif and the compile
>> fails.
> 
> 
> 
> Hi Steve-
> 
> As this is a bug, we'll track this issue at [1] to ensure we fix it and don't 
> duplicate our efforts.  For now, I've assigned it to myself.  If someone has 
> a working solution already, let me know.
> 
> -Seth
> 
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1831643

Thanks Seth.  I'll place my test results in the bug.  But in brief, it didn't 
work for me - with the patch applied, I now get a "file not found" error.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure - probably a race generating template_fieldnames_lexer.h

2019-06-04 Thread Seth Hillbrand

On 2019-06-04 11:07, Steven A. Falco wrote:

I think I just hit the builder race condition that was discussed a few
days ago.  I've attached a copy of template_fieldnames_lexer.h.  At
line 184 there is an #endif, and then part of the file appears to
repeat.  Thus, I wind up with an unmatched #endif and the compile
fails.




Hi Steve-

As this is a bug, we'll track this issue at [1] to ensure we fix it and 
don't duplicate our efforts.  For now, I've assigned it to myself.  If 
someone has a working solution already, let me know.


-Seth


[1] https://bugs.launchpad.net/kicad/+bug/1831643

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure - probably a race generating template_fieldnames_lexer.h

2019-06-04 Thread Steven A. Falco
I think I just hit the builder race condition that was discussed a few days 
ago.  I've attached a copy of template_fieldnames_lexer.h.  At line 184 there 
is an #endif, and then part of the file appears to repeat.  Thus, I wind up 
with an unmatched #endif and the compile fails.

I tried re-running the build, but it failed again, this time with 
dialog_bom_cfg_lexer.h messed up in a similar way.

Is there any workaround?

Steve

/* Do not modify this file it was automatically generated by the
 * TokenList2DsnLexer CMake script.
 */

#ifndef TEMPLATE_FIELDNAMES_LEXER_H_
#define TEMPLATE_FIELDNAMES_LEXER_H_

#include 

/**
 * C++ does not put enum _values_ in separate namespaces unless the enum itself
 * is in a separate namespace.  All the token enums must be in separate namespaces
 * otherwise the C++ compiler will eventually complain if it sees more than one
 * DSNLEXER in the same compilation unit, say by mutliple header file inclusion.
 * Plus this also enables re-use of the same enum name T.  A typedef can always be used
 * to clarify which enum T is in play should that ever be a problem.  This is
 * unlikely since Parse() functions will usually only be exposed to one header
 * file like this one.  But if there is a problem, then use:
 *   typedef TFIELD_T::T T;
 * within that problem area.
 */
namespace TFIELD_T
{
/// enum T contains all this lexer's tokens.
enum T
{
// these first few are negative special ones for syntax, and are
// inherited from DSNLEXER.
T_NONE  = DSN_NONE,
T_COMMENT   = DSN_COMMENT,
T_STRING_QUOTE  = DSN_STRING_QUOTE,
T_QUOTE_DEF = DSN_QUOTE_DEF,
T_DASH  = DSN_DASH,
T_SYMBOL= DSN_SYMBOL,
T_NUMBER= DSN_NUMBER,
T_RIGHT = DSN_RIGHT,// right bracket: ')'
T_LEFT  = DSN_LEFT, // left bracket:  '('
T_STRING= DSN_STRING,   // a quoted string, stripped of the quotes
T_EOF   = DSN_EOF,  // special case for end of file

T_field = 0,
T_name,
T_templatefields,
T_url,
T_value,
T_visible
};
}   // namespace TFIELD_T


/**
 * Class TEMPLATE_FIELDNAMES_LEXER
 * is an automatically generated class using the TokenList2DnsLexer.cmake
 * technology, based on keywords provided by file:
 */builddir/build/BUILD/kicad-r15989-e3c12355/eeschema/template_fieldnames.keywords
 */
class TEMPLATE_FIELDNAMES_LEXER : public DSNLEXER
{
/// Auto generated lexer keywords table and length:
static const KEYWORD  keywords[];
static const unsigned keyword_count;

public:
/**
 * Constructor ( const std::string&, const wxString& )
 * @param aSExpression is (utf8) text possibly from the clipboard that you want to parse.
 * @param aSource is a description of the origin of @a aSExpression, such as a filename.
 *   If left empty, then _("clipboard") is used.
 */
TEMPLATE_FIELDNAMES_LEXER( const std::string& aSExpression, const wxString& aSource = wxEmptyString ) :
DSNLEXER( keywords, keyword_count, aSExpression, aSource )
{
}

/**
 * Constructor ( FILE* )
 * takes @a aFile already opened for reading and @a aFilename as parameters.
 * The opened file is assumed to be positioned at the beginning of the file
 * for purposes of accurate line number reporting in error messages.  The
 * FILE is closed by this instance when its destructor is called.
 * @param aFile is a FILE already opened for reading.
 * @param aFilename is the name of the opened file, needed for error reporting.
 */
TEMPLATE_FIELDNAMES_LEXER( FILE* aFile, const wxString& aFilename ) :
DSNLEXER( keywords, keyword_count, aFile, aFilename )
{
}

/**
 * Constructor ( LINE_READER* )
 * intializes a lexer and prepares to read from @a aLineReader which
 * is assumed ready, and may be in use by other DSNLEXERs also.  No ownership
 * is taken of @a aLineReader. This enables it to be used by other lexers also.
 * The transition between grammars in such a case, must happen on a text
 * line boundary, not within the same line of text.
 *
 * @param aLineReader is any subclassed instance of LINE_READER, such as
 *  STRING_LINE_READER or FILE_LINE_READER.  No ownership is taken of aLineReader.
 */
TEMPLATE_FIELDNAMES_LEXER( LINE_READER* aLineReader ) :
DSNLEXER( keywords, keyword_count, aLineReader )
{
}

/**
 * Function TokenName
 * returns the name of the token in ASCII form.
 */
static const char* TokenName( TFIELD_T::T aTok );

/**
 * Function NextTok
 * returns the next token found in the input file or T_EOF when reaching
 * the end of file.  Users should wrap this function to return an enum
 * to aid in grammar debugging while running under a debugger, but leave
 * this lower 

Re: [Kicad-developers] Build failure of 5.1.2 in Fedora rawhide

2019-05-08 Thread Steven A. Falco
Here is the top of pcbnew.py, and I'll paste this into the bug report:

# This file was automatically generated by SWIG (http://www.swig.org).
# Version 4.0.0
#
# Do not make changes to this file unless you know what you are doing--modify
# the SWIG interface file instead.

from sys import version_info as _swig_python_version_info
if _swig_python_version_info < (2, 7, 0):
raise RuntimeError('Python 2.7 or later required')



On 5/8/19 9:42 AM, Steven A. Falco wrote:
> Yes.  swig-4.0.0-1.fc31.x86_64
> 
> On 5/8/19 9:40 AM, Nick Østergaard wrote:
>> Is the swig version 4.0.0?
>>
>> ons. 8. maj 2019 15.39 skrev Steven A. Falco > >:
>>
>> I've started getting a build error on 5.1.2 in Fedora rawhide.  Here is 
>> part of the log:
>>
>> [ 68%] Generating pcbnew_wrap.cxx, pcbnew.py
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E 
>> make_directory /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E touch 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings/docstrings.i
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/swig -python 
>> -c++ -outdir /builddir/build/BUILD/kicad-5.1.2/pcbnew 
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew 
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../include 
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../scripting 
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../common/swig -I -DHAVE_STDINT_H 
>> -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 
>> -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX 
>> -DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SPICE -DKICAD_USE_OCE 
>> -DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL 
>> -D__WXGTK__ -DUSE_WX_OVERLAY -DPCBNEW -o 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/python3 
>> /builddir/build/BUILD/kicad-5.1.2/scripting/build_tools/fix_swig_imports.py 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>> Error: the swig import helper was not fixed, check 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>>        and fix this script: fix_swig_imports.py
>>
>> I've uploaded the complete build log here:
>>
>> https://www.dropbox.com/s/1c822nrmpi9go2x/build.log?dl=0
>>
>> If a patch can be generated for this, I'll apply it.  Or if folks prefer 
>> to wait until 5.1.3 (if any), then that would be fine too.
>>
>> There are also some warnings in the build log that I uploaded, so I'll 
>> paste them in here for easy reference, in case they are of interest:
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/common.h:380: Warning 
>> 317: Specialization of non-template 'less'.
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/eda_text.h:45: Warning 
>> 401: Nothing known about base class 'std::mutex'. Ignored.
>> BUILDSTDERR: class_board.h:51: Warning 315: Nothing known about 
>> 'std::unique_ptr'.
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/polygon/clipper.cpp:892:38: warning: 
>> 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 
>> 'struct ClipperLib::TEdge'; use assignment or value-initialization instead 
>> [-Wclass-memaccess]
>> BUILDSTDERR:   892 |     std::memset( e, 0, sizeof(TEdge) );
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/common/kicad_curl/kicad_curl.cpp:49:13: 
>> warning: 'void lock_callback(int, int, const char*, int)' defined but not 
>> used [-Wunused-function]
>> BUILDSTDERR:    49 | static void lock_callback( int mode, int type, 
>> const char* file, int line )
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/include/math/vector2d.h:323:5: warning: 
>> '*((void*)& cursorSetting +16)' may be used uninitialized in this function 
>> [-Wmaybe-uninitialized]
>> BUILDSTDERR:   323 |     x = aVector.x;
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/board_design_settings.cpp:380:35: 
>> warning: comparison of integer expressions of different signedness: 'int' 
>> and 'unsigned int' [-Wsign-compare]
>> BUILDSTDERR:   380 |         for( int index = 0; index <= 
>> m_Pt_param->GetCount(); ++index )
>>
>> BUILDSTDERR: 
>> /builddir/build/BUILD/kicad-5.1.2/eeschema/dialogs/dialog_spice_model.cpp:809:38:
>>  warning: dereferencing type-punned pointer will break strict-aliasing rules 
>> [-Wstrict-aliasing]
>> BUILDSTDERR:   809 |     m_pwlValList->SetItemData( idx, 
>> *reinterpret_cast(  ) );
>>
>>         Steve
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : 

Re: [Kicad-developers] Build failure of 5.1.2 in Fedora rawhide

2019-05-08 Thread Steven A. Falco
Yes.  swig-4.0.0-1.fc31.x86_64

On 5/8/19 9:40 AM, Nick Østergaard wrote:
> Is the swig version 4.0.0?
> 
> ons. 8. maj 2019 15.39 skrev Steven A. Falco  >:
> 
> I've started getting a build error on 5.1.2 in Fedora rawhide.  Here is 
> part of the log:
> 
> [ 68%] Generating pcbnew_wrap.cxx, pcbnew.py
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E 
> make_directory /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E touch 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings/docstrings.i
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/swig -python -c++ 
> -outdir /builddir/build/BUILD/kicad-5.1.2/pcbnew 
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew 
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../include 
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../scripting 
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../common/swig -I -DHAVE_STDINT_H 
> -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 
> -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX 
> -DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SPICE -DKICAD_USE_OCE 
> -DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL 
> -D__WXGTK__ -DUSE_WX_OVERLAY -DPCBNEW -o 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/python3 
> /builddir/build/BUILD/kicad-5.1.2/scripting/build_tools/fix_swig_imports.py 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
> Error: the swig import helper was not fixed, check 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>        and fix this script: fix_swig_imports.py
> 
> I've uploaded the complete build log here:
> 
> https://www.dropbox.com/s/1c822nrmpi9go2x/build.log?dl=0
> 
> If a patch can be generated for this, I'll apply it.  Or if folks prefer 
> to wait until 5.1.3 (if any), then that would be fine too.
> 
> There are also some warnings in the build log that I uploaded, so I'll 
> paste them in here for easy reference, in case they are of interest:
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/common.h:380: Warning 
> 317: Specialization of non-template 'less'.
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/eda_text.h:45: Warning 
> 401: Nothing known about base class 'std::mutex'. Ignored.
> BUILDSTDERR: class_board.h:51: Warning 315: Nothing known about 
> 'std::unique_ptr'.
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/polygon/clipper.cpp:892:38: warning: 'void* 
> memset(void*, int, size_t)' clearing an object of non-trivial type 'struct 
> ClipperLib::TEdge'; use assignment or value-initialization instead 
> [-Wclass-memaccess]
> BUILDSTDERR:   892 |     std::memset( e, 0, sizeof(TEdge) );
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/common/kicad_curl/kicad_curl.cpp:49:13: 
> warning: 'void lock_callback(int, int, const char*, int)' defined but not 
> used [-Wunused-function]
> BUILDSTDERR:    49 | static void lock_callback( int mode, int type, const 
> char* file, int line )
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/include/math/vector2d.h:323:5: warning: 
> '*((void*)& cursorSetting +16)' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
> BUILDSTDERR:   323 |     x = aVector.x;
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/board_design_settings.cpp:380:35: 
> warning: comparison of integer expressions of different signedness: 'int' and 
> 'unsigned int' [-Wsign-compare]
> BUILDSTDERR:   380 |         for( int index = 0; index <= 
> m_Pt_param->GetCount(); ++index )
> 
> BUILDSTDERR: 
> /builddir/build/BUILD/kicad-5.1.2/eeschema/dialogs/dialog_spice_model.cpp:809:38:
>  warning: dereferencing type-punned pointer will break strict-aliasing rules 
> [-Wstrict-aliasing]
> BUILDSTDERR:   809 |     m_pwlValList->SetItemData( idx, 
> *reinterpret_cast(  ) );
> 
>         Steve
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure of 5.1.2 in Fedora rawhide

2019-05-08 Thread Nick Østergaard
https://bugs.launchpad.net/kicad/+bug/1816286

ons. 8. maj 2019 15.40 skrev Nick Østergaard :

> Is the swig version 4.0.0?
>
> ons. 8. maj 2019 15.39 skrev Steven A. Falco :
>
>> I've started getting a build error on 5.1.2 in Fedora rawhide.  Here is
>> part of the log:
>>
>> [ 68%] Generating pcbnew_wrap.cxx, pcbnew.py
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E
>> make_directory /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E touch
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings/docstrings.i
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/swig -python -c++
>> -outdir /builddir/build/BUILD/kicad-5.1.2/pcbnew
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../include
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../scripting
>> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../common/swig -I
>> -DHAVE_STDINT_H -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES
>> -DKICAD_SCRIPTING_PYTHON3 -DKICAD_SCRIPTING_WXPYTHON
>> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SCRIPTING_ACTION_MENU
>> -DKICAD_SPICE -DKICAD_USE_OCE -DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY
>> -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -DUSE_WX_OVERLAY -DPCBNEW
>> -o /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
>> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/python3
>> /builddir/build/BUILD/kicad-5.1.2/scripting/build_tools/fix_swig_imports.py
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>> Error: the swig import helper was not fixed, check
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>>and fix this script: fix_swig_imports.py
>>
>> I've uploaded the complete build log here:
>>
>> https://www.dropbox.com/s/1c822nrmpi9go2x/build.log?dl=0
>>
>> If a patch can be generated for this, I'll apply it.  Or if folks prefer
>> to wait until 5.1.3 (if any), then that would be fine too.
>>
>> There are also some warnings in the build log that I uploaded, so I'll
>> paste them in here for easy reference, in case they are of interest:
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/common.h:380: Warning
>> 317: Specialization of non-template 'less'.
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/eda_text.h:45: Warning
>> 401: Nothing known about base class 'std::mutex'. Ignored.
>> BUILDSTDERR: class_board.h:51: Warning 315: Nothing known about
>> 'std::unique_ptr'.
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/polygon/clipper.cpp:892:38: warning:
>> 'void* memset(void*, int, size_t)' clearing an object of non-trivial type
>> 'struct ClipperLib::TEdge'; use assignment or value-initialization instead
>> [-Wclass-memaccess]
>> BUILDSTDERR:   892 | std::memset( e, 0, sizeof(TEdge) );
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/common/kicad_curl/kicad_curl.cpp:49:13:
>> warning: 'void lock_callback(int, int, const char*, int)' defined but not
>> used [-Wunused-function]
>> BUILDSTDERR:49 | static void lock_callback( int mode, int type, const
>> char* file, int line )
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/include/math/vector2d.h:323:5: warning:
>> '*((void*)& cursorSetting +16)' may be used uninitialized in this function
>> [-Wmaybe-uninitialized]
>> BUILDSTDERR:   323 | x = aVector.x;
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/pcbnew/board_design_settings.cpp:380:35:
>> warning: comparison of integer expressions of different signedness: 'int'
>> and 'unsigned int' [-Wsign-compare]
>> BUILDSTDERR:   380 | for( int index = 0; index <=
>> m_Pt_param->GetCount(); ++index )
>>
>> BUILDSTDERR:
>> /builddir/build/BUILD/kicad-5.1.2/eeschema/dialogs/dialog_spice_model.cpp:809:38:
>> warning: dereferencing type-punned pointer will break strict-aliasing rules
>> [-Wstrict-aliasing]
>> BUILDSTDERR:   809 | m_pwlValList->SetItemData( idx,
>> *reinterpret_cast(  ) );
>>
>> Steve
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure of 5.1.2 in Fedora rawhide

2019-05-08 Thread Nick Østergaard
Is the swig version 4.0.0?

ons. 8. maj 2019 15.39 skrev Steven A. Falco :

> I've started getting a build error on 5.1.2 in Fedora rawhide.  Here is
> part of the log:
>
> [ 68%] Generating pcbnew_wrap.cxx, pcbnew.py
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E
> make_directory /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E touch
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings/docstrings.i
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/swig -python -c++
> -outdir /builddir/build/BUILD/kicad-5.1.2/pcbnew
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../include
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../scripting
> -I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../common/swig -I
> -DHAVE_STDINT_H -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES
> -DKICAD_SCRIPTING_PYTHON3 -DKICAD_SCRIPTING_WXPYTHON
> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SCRIPTING_ACTION_MENU
> -DKICAD_SPICE -DKICAD_USE_OCE -DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY
> -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -DUSE_WX_OVERLAY -DPCBNEW
> -o /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
> cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/python3
> /builddir/build/BUILD/kicad-5.1.2/scripting/build_tools/fix_swig_imports.py
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
> Error: the swig import helper was not fixed, check
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
>and fix this script: fix_swig_imports.py
>
> I've uploaded the complete build log here:
>
> https://www.dropbox.com/s/1c822nrmpi9go2x/build.log?dl=0
>
> If a patch can be generated for this, I'll apply it.  Or if folks prefer
> to wait until 5.1.3 (if any), then that would be fine too.
>
> There are also some warnings in the build log that I uploaded, so I'll
> paste them in here for easy reference, in case they are of interest:
>
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/common.h:380: Warning
> 317: Specialization of non-template 'less'.
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/eda_text.h:45: Warning
> 401: Nothing known about base class 'std::mutex'. Ignored.
> BUILDSTDERR: class_board.h:51: Warning 315: Nothing known about
> 'std::unique_ptr'.
>
> BUILDSTDERR: /builddir/build/BUILD/kicad-5.1.2/polygon/clipper.cpp:892:38:
> warning: 'void* memset(void*, int, size_t)' clearing an object of
> non-trivial type 'struct ClipperLib::TEdge'; use assignment or
> value-initialization instead [-Wclass-memaccess]
> BUILDSTDERR:   892 | std::memset( e, 0, sizeof(TEdge) );
>
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/common/kicad_curl/kicad_curl.cpp:49:13:
> warning: 'void lock_callback(int, int, const char*, int)' defined but not
> used [-Wunused-function]
> BUILDSTDERR:49 | static void lock_callback( int mode, int type, const
> char* file, int line )
>
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/include/math/vector2d.h:323:5: warning:
> '*((void*)& cursorSetting +16)' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> BUILDSTDERR:   323 | x = aVector.x;
>
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/pcbnew/board_design_settings.cpp:380:35:
> warning: comparison of integer expressions of different signedness: 'int'
> and 'unsigned int' [-Wsign-compare]
> BUILDSTDERR:   380 | for( int index = 0; index <=
> m_Pt_param->GetCount(); ++index )
>
> BUILDSTDERR:
> /builddir/build/BUILD/kicad-5.1.2/eeschema/dialogs/dialog_spice_model.cpp:809:38:
> warning: dereferencing type-punned pointer will break strict-aliasing rules
> [-Wstrict-aliasing]
> BUILDSTDERR:   809 | m_pwlValList->SetItemData( idx,
> *reinterpret_cast(  ) );
>
> Steve
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure of 5.1.2 in Fedora rawhide

2019-05-08 Thread Steven A. Falco
I've started getting a build error on 5.1.2 in Fedora rawhide.  Here is part of 
the log:

[ 68%] Generating pcbnew_wrap.cxx, pcbnew.py
cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E make_directory 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings
cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/cmake -E touch 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/docstrings/docstrings.i
cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/swig -python -c++ 
-outdir /builddir/build/BUILD/kicad-5.1.2/pcbnew 
-I/builddir/build/BUILD/kicad-5.1.2/pcbnew 
-I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../include 
-I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../scripting 
-I/builddir/build/BUILD/kicad-5.1.2/pcbnew/../common/swig -I -DHAVE_STDINT_H 
-DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX 
-DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SPICE -DKICAD_USE_OCE 
-DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL 
-D__WXGTK__ -DUSE_WX_OVERLAY -DPCBNEW -o 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
cd /builddir/build/BUILD/kicad-5.1.2/pcbnew && /usr/bin/python3 
/builddir/build/BUILD/kicad-5.1.2/scripting/build_tools/fix_swig_imports.py 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
Error: the swig import helper was not fixed, check 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/pcbnew.py
   and fix this script: fix_swig_imports.py

I've uploaded the complete build log here:

https://www.dropbox.com/s/1c822nrmpi9go2x/build.log?dl=0

If a patch can be generated for this, I'll apply it.  Or if folks prefer to 
wait until 5.1.3 (if any), then that would be fine too.

There are also some warnings in the build log that I uploaded, so I'll paste 
them in here for easy reference, in case they are of interest:

BUILDSTDERR: /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/common.h:380: 
Warning 317: Specialization of non-template 'less'.
BUILDSTDERR: /builddir/build/BUILD/kicad-5.1.2/pcbnew/../include/eda_text.h:45: 
Warning 401: Nothing known about base class 'std::mutex'. Ignored.
BUILDSTDERR: class_board.h:51: Warning 315: Nothing known about 
'std::unique_ptr'.

BUILDSTDERR: /builddir/build/BUILD/kicad-5.1.2/polygon/clipper.cpp:892:38: 
warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial 
type 'struct ClipperLib::TEdge'; use assignment or value-initialization instead 
[-Wclass-memaccess]
BUILDSTDERR:   892 | std::memset( e, 0, sizeof(TEdge) );

BUILDSTDERR: 
/builddir/build/BUILD/kicad-5.1.2/common/kicad_curl/kicad_curl.cpp:49:13: 
warning: 'void lock_callback(int, int, const char*, int)' defined but not used 
[-Wunused-function]
BUILDSTDERR:49 | static void lock_callback( int mode, int type, const char* 
file, int line )

BUILDSTDERR: /builddir/build/BUILD/kicad-5.1.2/include/math/vector2d.h:323:5: 
warning: '*((void*)& cursorSetting +16)' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
BUILDSTDERR:   323 | x = aVector.x;

BUILDSTDERR: 
/builddir/build/BUILD/kicad-5.1.2/pcbnew/board_design_settings.cpp:380:35: 
warning: comparison of integer expressions of different signedness: 'int' and 
'unsigned int' [-Wsign-compare]
BUILDSTDERR:   380 | for( int index = 0; index <= 
m_Pt_param->GetCount(); ++index )

BUILDSTDERR: 
/builddir/build/BUILD/kicad-5.1.2/eeschema/dialogs/dialog_spice_model.cpp:809:38:
 warning: dereferencing type-punned pointer will break strict-aliasing rules 
[-Wstrict-aliasing]
BUILDSTDERR:   809 | m_pwlValList->SetItemData( idx, 
*reinterpret_cast(  ) );

Steve




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on Fedora 29

2018-12-09 Thread Steven A. Falco
On 12/9/18 11:53 AM, Steven A. Falco wrote:
> On 12/9/18 10:47 AM, Seth Hillbrand wrote:
>> Am 2018-12-09 10:24, schrieb Steven A. Falco:
>>> I had been able to build KiCad successfully for Fedora 29, but
>>> something has apparently changed very recently, because I am now
>>> getting a build failure.
>>>
>>> Below is part of my build log.  The error relates to an include file
>>> called KHR/khrplatform.h:
>>>
>>> [ 23%] Building CXX object
>>
>>> /builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp:42:
>>> BUILDSTDERR: /usr/include/GL/glext.h:467:10: fatal error:
>>> KHR/khrplatform.h: No such file or directory
>>> BUILDSTDERR:  #include 
>>> BUILDSTDERR:   ^~~
>>
>>> Does anyone have an idea as to what is going on?  Is it a Fedora bug
>>> or a KiCad bug?
>>>
>>> Steve
>>
>> Hi Steve-
>>
>> That is the Khronos group header file that is used for older OpenGL 
>> implementations.  It is still included from the glext.h file.
>>
>> It may be that the Fedora packaging changed who provides this file or the 
>> dependencies.  Do you require mesa-libEGL-devel-** for the build?  If not, 
>> adding it should fix the issue.
>>
>> -S
>>
> 
> Thanks much.  Adding mesa-libEGL-devel looks like it fixes the build.  I have 
> more testing to do, but once I am confident, I'll create a pull request to 
> fix the nightlies, and also push the fix into the official Fedora build 
> system.
> 
>   Steve
> 
> 

I completed my testing, and adding a BuildRequires for mesa-libEGL-devel does 
indeed fix the Fedora 29 build.  I've opened a pull request:

https://github.com/KiCad/fedora-packaging/pull/22

which should fix the nightly Fedora builds.

Steve

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on Fedora 29

2018-12-09 Thread Steven A. Falco
On 12/9/18 10:47 AM, Seth Hillbrand wrote:
> Am 2018-12-09 10:24, schrieb Steven A. Falco:
>> I had been able to build KiCad successfully for Fedora 29, but
>> something has apparently changed very recently, because I am now
>> getting a build failure.
>>
>> Below is part of my build log.  The error relates to an include file
>> called KHR/khrplatform.h:
>>
>> [ 23%] Building CXX object
> 
>> /builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp:42:
>> BUILDSTDERR: /usr/include/GL/glext.h:467:10: fatal error:
>> KHR/khrplatform.h: No such file or directory
>> BUILDSTDERR:  #include 
>> BUILDSTDERR:   ^~~
> 
>> Does anyone have an idea as to what is going on?  Is it a Fedora bug
>> or a KiCad bug?
>>
>> Steve
> 
> Hi Steve-
> 
> That is the Khronos group header file that is used for older OpenGL 
> implementations.  It is still included from the glext.h file.
> 
> It may be that the Fedora packaging changed who provides this file or the 
> dependencies.  Do you require mesa-libEGL-devel-** for the build?  If not, 
> adding it should fix the issue.
> 
> -S
> 

Thanks much.  Adding mesa-libEGL-devel looks like it fixes the build.  I have 
more testing to do, but once I am confident, I'll create a pull request to fix 
the nightlies, and also push the fix into the official Fedora build system.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on Fedora 29

2018-12-09 Thread Bob Gustafson

This might be the problem: (not Kicad)

https://bugs.freedesktop.org/show_bug.cgi?id=77240

On 12/9/18 9:24 AM, Steven A. Falco wrote:

I had been able to build KiCad successfully for Fedora 29, but something has 
apparently changed very recently, because I am now getting a build failure.

Below is part of my build log.  The error relates to an include file called 
KHR/khrplatform.h:

[ 23%] Building CXX object 
common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o
cd /builddir/build/BUILD/kicad-5.0.2/common && /usr/bin/c++  
-DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_USE_OCE -DWXUSINGDLL -DWX_COMPATIBILITY 
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -DPCBNEW -I/builddir/build/BUILD/kicad-5.0.2/include 
-I/builddir/build/BUILD/kicad-5.0.2/common/. 
-I/builddir/build/BUILD/kicad-5.0.2/common/./dialogs 
-I/builddir/build/BUILD/kicad-5.0.2/common/./widgets 
-I/builddir/build/BUILD/kicad-5.0.2/common/./dialog_about -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer 
-I/builddir/build/BUILD/kicad-5.0.2/common/../pcbnew 
-I/builddir/build/BUILD/kicad-5.0.2/common/../polygon 
-I/builddir/build/BUILD/kicad-5.0.2 -I/usr/lib64/oce-0.18/../../include/oce -isystem 
/usr/lib64/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0  -Wall -O2 -g -pipe 
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wsuggest-override -Wno-unused-local-typedefs -Wno-strict-aliasing -pthread -Wshadow 
-DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   -std=gnu++11 -o 
CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o -c 
/builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp
BUILDSTDERR: In file included from /usr/include/GL/gl.h:2055,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/../../common_ogl/openGL_includes.h:39,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/clayer_triangles.h:33,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/c3d_render_ogl_legacy.h:34,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_viewer/../3d_canvas/eda_3d_canvas.h:36,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_viewer/eda_3d_viewer.h:37,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp:42:
BUILDSTDERR: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No 
such file or directory
BUILDSTDERR:  #include 
BUILDSTDERR:   ^~~
BUILDSTDERR: compilation terminated.
BUILDSTDERR: make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:179: 
common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/kicad-5.0.2'
BUILDSTDERR: make[2]: *** Waiting for unfinished jobs

I just checked the nightly builds, and they too are failing.  Here is the error 
from Copr - it also involves KHR/khrplatform.h:

[  3%] Building CXX object common/CMakeFiles/gal.dir/gl_context_mgr.cpp.o
cd /builddir/build/BUILD/kicad-r14589-dd9a0010/common && /usr/bin/c++  
-DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_SCRIPTING -DKICAD_SCRIPTING_ACTION_MENU 
-DKICAD_SCRIPTING_MODULES -DKICAD_USE_OCE -DWXUSINGDLL -DWX_COMPATIBILITY 
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/include 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/. 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./dialogs 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./widgets 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./dialog_about 
-I/usr/include/cairo -I/usr/include/pixman-1 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../3d-viewer 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../pcbnew 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../polygon 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010 -I/usr/include/python2.7 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/scripting 
-I/usr/lib64/oce-0.18/../../include/oce -isystem /usr/lib64/wx/include/gtk2-unicode-3.0 
-isystem /usr/include/wx-3.0  -Wall -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wsuggest-override -Werror=vla -Wno-unused-local-typedefs -Wno-strict-aliasing -pthread 

Re: [Kicad-developers] Build failure on Fedora 29

2018-12-09 Thread Seth Hillbrand

Am 2018-12-09 10:24, schrieb Steven A. Falco:

I had been able to build KiCad successfully for Fedora 29, but
something has apparently changed very recently, because I am now
getting a build failure.

Below is part of my build log.  The error relates to an include file
called KHR/khrplatform.h:

[ 23%] Building CXX object



/builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp:42:
BUILDSTDERR: /usr/include/GL/glext.h:467:10: fatal error:
KHR/khrplatform.h: No such file or directory
BUILDSTDERR:  #include 
BUILDSTDERR:   ^~~



Does anyone have an idea as to what is going on?  Is it a Fedora bug
or a KiCad bug?

Steve


Hi Steve-

That is the Khronos group header file that is used for older OpenGL 
implementations.  It is still included from the glext.h file.


It may be that the Fedora packaging changed who provides this file or 
the dependencies.  Do you require mesa-libEGL-devel-** for the build?  
If not, adding it should fix the issue.


-S

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure on Fedora 29

2018-12-09 Thread Steven A. Falco
I had been able to build KiCad successfully for Fedora 29, but something has 
apparently changed very recently, because I am now getting a build failure.

Below is part of my build log.  The error relates to an include file called 
KHR/khrplatform.h:

[ 23%] Building CXX object 
common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o
cd /builddir/build/BUILD/kicad-5.0.2/common && /usr/bin/c++  
-DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_USE_OCE -DWXUSINGDLL 
-DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -DPCBNEW 
-I/builddir/build/BUILD/kicad-5.0.2/include 
-I/builddir/build/BUILD/kicad-5.0.2/common/. 
-I/builddir/build/BUILD/kicad-5.0.2/common/./dialogs 
-I/builddir/build/BUILD/kicad-5.0.2/common/./widgets 
-I/builddir/build/BUILD/kicad-5.0.2/common/./dialog_about -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer 
-I/builddir/build/BUILD/kicad-5.0.2/common/../pcbnew 
-I/builddir/build/BUILD/kicad-5.0.2/common/../polygon 
-I/builddir/build/BUILD/kicad-5.0.2 -I/usr/lib64/oce-0.18/../../include/oce 
-isystem /usr/lib64/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0  
-Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wsuggest-override -Wno-unused-local-typedefs -Wno-strict-aliasing -pthread 
-Wshadow -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   
-std=gnu++11 -o CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o -c 
/builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp
BUILDSTDERR: In file included from /usr/include/GL/gl.h:2055,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/../../common_ogl/openGL_includes.h:39,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/clayer_triangles.h:33,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_rendering/3d_render_ogl_legacy/c3d_render_ogl_legacy.h:34,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_viewer/../3d_canvas/eda_3d_canvas.h:36,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/common/../3d-viewer/3d_viewer/eda_3d_viewer.h:37,
BUILDSTDERR:  from 
/builddir/build/BUILD/kicad-5.0.2/pcbnew/pcb_base_frame.cpp:42:
BUILDSTDERR: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No 
such file or directory
BUILDSTDERR:  #include 
BUILDSTDERR:   ^~~
BUILDSTDERR: compilation terminated.
BUILDSTDERR: make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:179: 
common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_base_frame.cpp.o] Error 1
make[2]: Leaving directory '/builddir/build/BUILD/kicad-5.0.2'
BUILDSTDERR: make[2]: *** Waiting for unfinished jobs

I just checked the nightly builds, and they too are failing.  Here is the error 
from Copr - it also involves KHR/khrplatform.h:

[  3%] Building CXX object common/CMakeFiles/gal.dir/gl_context_mgr.cpp.o
cd /builddir/build/BUILD/kicad-r14589-dd9a0010/common && /usr/bin/c++  
-DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_SCRIPTING 
-DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SCRIPTING_MODULES -DKICAD_USE_OCE 
-DWXUSINGDLL -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/include 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/. 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./dialogs 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./widgets 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/./dialog_about 
-I/usr/include/cairo -I/usr/include/pixman-1 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../3d-viewer 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../pcbnew 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/common/../polygon 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010 -I/usr/include/python2.7 
-I/builddir/build/BUILD/kicad-r14589-dd9a0010/scripting 
-I/usr/lib64/oce-0.18/../../include/oce -isystem 
/usr/lib64/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0  -Wall -O2 
-g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wsuggest-override -Werror=vla -Wno-unused-local-typedefs -Wno-strict-aliasing 
-pthread -Wshadow -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden   -std=gnu++11 -o 

Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
Those are awesome; MUCH better than the old build documentation.  I must have 
missed them when they came out.

Cheers,
Jeff.

> On 2 Nov 2018, at 22:54, Adam Wolf  wrote:
> 
> Take a look at https://github.com/KiCad/kicad-mac-builder 
>  which is super awesome and 
> should be better than those shell scripts in every way. :)  If the old stuff 
> is better than the new stuff, please let me know how I can improve the new :)
> 
> Thanks!
> 
> On Fri, Nov 2, 2018, 4:50 PM Maciej Suminski   wrote:
> I am not a Mac guru, so I have followed a lazy path of
> KiCadMacOSPackaging [1] script by Adam Wolf, which got me cairo library
> as well.
> 
> Cheers,
> Orson
> 
> 1.
> https://github.com/wayneandlayne/KiCadMacOSPackaging/blob/master/setup.sh#L27 
> 
> 
> On 11/2/18 8:47 PM, Jeff Young wrote:
> > CLion must have been holding on to something somewhere.  Invalidating 
> > CLion’s caches and restarting did the deed.
> > 
> > So my best guess is that you need to “brew install cairo”, and at least 
> > rerun CMake (possibly also needing to flush your devenv's caches).
> > 
> > Have we added cairo to the list of pre-requisties in the build instructions?
> > 
> > Cheers,
> > Jeff.
> > 
> >> On 2 Nov 2018, at 13:27, Maciej Suminski  >> > wrote:
> >>
> >> Hi Jeff,
> >>
> >> I copied and adjusted your cmake spell, and it works fine for me on
> >> macOS 10.13 with cairo installed via brew. One difference I spotted is
> >> that I have cairo_quartz.h in
> >> /usr/local/Cellar/cairo/1.14.12/include/cairo/.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 11/2/18 1:58 PM, Jeff Young wrote:
> >>> CLion.  CMake args:
> >>>
> >>> -DCMAKE_C_COMPILER=clang
> >>> -DCMAKE_CXX_COMPILER=clang++
> >>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
> >>> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
> >>> -DKICAD_SCRIPTING=ON
> >>> -DKICAD_SCRIPTING_MODULES=OFF
> >>> -DKICAD_SCRIPTING_WXPYTHON=OFF
> >>> -DKICAD_USE_OCE=OFF
> >>> -DCMAKE_INSTALL_PREFIX=./bin
> >>> -DCMAKE_BUILD_TYPE=Debug
> >>> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
> >>>
> >>> Cheers,
> >>> Jeff.
> >>>
> >>>
>  On 2 Nov 2018, at 12:39, Adam Wolf   > wrote:
> 
>  How are you building?  What are your cmake arguments?
> 
>  Adam
> 
>  On Fri, Nov 2, 2018, 7:33 AM Jeff Young    > 
>     >> wrote:
>  I also tried “brew install cairo” to no avail.  I assume I need a 
>  Cairo.framework in my /system/library/frameworks, but I’m not sure how 
>  to get it there.
> 
> 
> > On 2 Nov 2018, at 10:28, Jeff Young  >  > 
> >   >  >
> > "cairo-quartz.h can’t be found”
> >
> > I have such a file at /opt/local/include/cairo/, but that’s evidently 
> > not where the dev system is looking.  Do I need to copy that somewhere, 
> > or does something in my setup need to be updated to look for it there?
> >
> > Thanks,
> > Jeff.
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> >  
> >  > > 
> >  >  
> >  > >>
> > Post to : kicad-developers@lists.launchpad.net 
> >  
> >  > > 
> >  >  
> >  > >>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> >  
> >  > > 
> >  >  
> >  > >>
> > More help   : https://help.launchpad.net/ListHelp 
> >  
> > 

Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Adam Wolf
Take a look at https://github.com/KiCad/kicad-mac-builder which is super
awesome and should be better than those shell scripts in every way. :)  If
the old stuff is better than the new stuff, please let me know how I can
improve the new :)

Thanks!

On Fri, Nov 2, 2018, 4:50 PM Maciej Suminski  I am not a Mac guru, so I have followed a lazy path of
> KiCadMacOSPackaging [1] script by Adam Wolf, which got me cairo library
> as well.
>
> Cheers,
> Orson
>
> 1.
>
> https://github.com/wayneandlayne/KiCadMacOSPackaging/blob/master/setup.sh#L27
>
> On 11/2/18 8:47 PM, Jeff Young wrote:
> > CLion must have been holding on to something somewhere.  Invalidating
> CLion’s caches and restarting did the deed.
> >
> > So my best guess is that you need to “brew install cairo”, and at least
> rerun CMake (possibly also needing to flush your devenv's caches).
> >
> > Have we added cairo to the list of pre-requisties in the build
> instructions?
> >
> > Cheers,
> > Jeff.
> >
> >> On 2 Nov 2018, at 13:27, Maciej Suminski 
> wrote:
> >>
> >> Hi Jeff,
> >>
> >> I copied and adjusted your cmake spell, and it works fine for me on
> >> macOS 10.13 with cairo installed via brew. One difference I spotted is
> >> that I have cairo_quartz.h in
> >> /usr/local/Cellar/cairo/1.14.12/include/cairo/.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 11/2/18 1:58 PM, Jeff Young wrote:
> >>> CLion.  CMake args:
> >>>
> >>> -DCMAKE_C_COMPILER=clang
> >>> -DCMAKE_CXX_COMPILER=clang++
> >>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
> >>> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
> >>> -DKICAD_SCRIPTING=ON
> >>> -DKICAD_SCRIPTING_MODULES=OFF
> >>> -DKICAD_SCRIPTING_WXPYTHON=OFF
> >>> -DKICAD_USE_OCE=OFF
> >>> -DCMAKE_INSTALL_PREFIX=./bin
> >>> -DCMAKE_BUILD_TYPE=Debug
> >>>
> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
> >>>
> >>> Cheers,
> >>> Jeff.
> >>>
> >>>
>  On 2 Nov 2018, at 12:39, Adam Wolf 
> wrote:
> 
>  How are you building?  What are your cmake arguments?
> 
>  Adam
> 
>  On Fri, Nov 2, 2018, 7:33 AM Jeff Young  j...@rokeby.ie> > wrote:
>  I also tried “brew install cairo” to no avail.  I assume I need a
> Cairo.framework in my /system/library/frameworks, but I’m not sure how to
> get it there.
> 
> 
> > On 2 Nov 2018, at 10:28, Jeff Young  j...@rokeby.ie> >> wrote:
> >
> > "cairo-quartz.h can’t be found”
> >
> > I have such a file at /opt/local/include/cairo/, but that’s
> evidently not where the dev system is looking.  Do I need to copy that
> somewhere, or does something in my setup need to be updated to look for it
> there?
> >
> > Thanks,
> > Jeff.
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers> <
> https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>  kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers> <
> https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>  >
> 
> 
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers> <
> https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>>
>  Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>  kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>>
>  Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers> <
> https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>>
>  More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>  >
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : 

Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Maciej Suminski
I am not a Mac guru, so I have followed a lazy path of
KiCadMacOSPackaging [1] script by Adam Wolf, which got me cairo library
as well.

Cheers,
Orson

1.
https://github.com/wayneandlayne/KiCadMacOSPackaging/blob/master/setup.sh#L27

On 11/2/18 8:47 PM, Jeff Young wrote:
> CLion must have been holding on to something somewhere.  Invalidating CLion’s 
> caches and restarting did the deed.
> 
> So my best guess is that you need to “brew install cairo”, and at least rerun 
> CMake (possibly also needing to flush your devenv's caches).
> 
> Have we added cairo to the list of pre-requisties in the build instructions?
> 
> Cheers,
> Jeff.
> 
>> On 2 Nov 2018, at 13:27, Maciej Suminski  wrote:
>>
>> Hi Jeff,
>>
>> I copied and adjusted your cmake spell, and it works fine for me on
>> macOS 10.13 with cairo installed via brew. One difference I spotted is
>> that I have cairo_quartz.h in
>> /usr/local/Cellar/cairo/1.14.12/include/cairo/.
>>
>> Cheers,
>> Orson
>>
>> On 11/2/18 1:58 PM, Jeff Young wrote:
>>> CLion.  CMake args:
>>>
>>> -DCMAKE_C_COMPILER=clang
>>> -DCMAKE_CXX_COMPILER=clang++
>>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
>>> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
>>> -DKICAD_SCRIPTING=ON
>>> -DKICAD_SCRIPTING_MODULES=OFF
>>> -DKICAD_SCRIPTING_WXPYTHON=OFF
>>> -DKICAD_USE_OCE=OFF
>>> -DCMAKE_INSTALL_PREFIX=./bin
>>> -DCMAKE_BUILD_TYPE=Debug
>>> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
 On 2 Nov 2018, at 12:39, Adam Wolf  wrote:

 How are you building?  What are your cmake arguments?

 Adam

 On Fri, Nov 2, 2018, 7:33 AM Jeff Young >>>  > 
 wrote:
 I also tried “brew install cairo” to no avail.  I assume I need a 
 Cairo.framework in my /system/library/frameworks, but I’m not sure how to 
 get it there.


> On 2 Nov 2018, at 10:28, Jeff Young   >> 
> wrote:
>
> "cairo-quartz.h can’t be found”
>
> I have such a file at /opt/local/include/cairo/, but that’s evidently not 
> where the dev system is looking.  Do I need to copy that somewhere, or 
> does something in my setup need to be updated to look for it there?
>
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
>  
>  >
> Post to : kicad-developers@lists.launchpad.net 
>  
>  >
> Unsubscribe : https://launchpad.net/~kicad-developers 
>  
>  >
> More help   : https://help.launchpad.net/ListHelp 
>  
>  >


 ___
 Mailing list: https://launchpad.net/~kicad-developers 
  
 >
 Post to : kicad-developers@lists.launchpad.net 
  
 >
 Unsubscribe : https://launchpad.net/~kicad-developers 
  
 >
 More help   : https://help.launchpad.net/ListHelp 
  >
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More 

Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
CLion must have been holding on to something somewhere.  Invalidating CLion’s 
caches and restarting did the deed.

So my best guess is that you need to “brew install cairo”, and at least rerun 
CMake (possibly also needing to flush your devenv's caches).

Have we added cairo to the list of pre-requisties in the build instructions?

Cheers,
Jeff.

> On 2 Nov 2018, at 13:27, Maciej Suminski  wrote:
> 
> Hi Jeff,
> 
> I copied and adjusted your cmake spell, and it works fine for me on
> macOS 10.13 with cairo installed via brew. One difference I spotted is
> that I have cairo_quartz.h in
> /usr/local/Cellar/cairo/1.14.12/include/cairo/.
> 
> Cheers,
> Orson
> 
> On 11/2/18 1:58 PM, Jeff Young wrote:
>> CLion.  CMake args:
>> 
>> -DCMAKE_C_COMPILER=clang
>> -DCMAKE_CXX_COMPILER=clang++
>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
>> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
>> -DKICAD_SCRIPTING=ON
>> -DKICAD_SCRIPTING_MODULES=OFF
>> -DKICAD_SCRIPTING_WXPYTHON=OFF
>> -DKICAD_USE_OCE=OFF
>> -DCMAKE_INSTALL_PREFIX=./bin
>> -DCMAKE_BUILD_TYPE=Debug
>> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 2 Nov 2018, at 12:39, Adam Wolf  wrote:
>>> 
>>> How are you building?  What are your cmake arguments?
>>> 
>>> Adam
>>> 
>>> On Fri, Nov 2, 2018, 7:33 AM Jeff Young >>  > 
>>> wrote:
>>> I also tried “brew install cairo” to no avail.  I assume I need a 
>>> Cairo.framework in my /system/library/frameworks, but I’m not sure how to 
>>> get it there.
>>> 
>>> 
 On 2 Nov 2018, at 10:28, Jeff Young >>>  >> 
 wrote:
 
 "cairo-quartz.h can’t be found”
 
 I have such a file at /opt/local/include/cairo/, but that’s evidently not 
 where the dev system is looking.  Do I need to copy that somewhere, or 
 does something in my setup need to be updated to look for it there?
 
 Thanks,
 Jeff.
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
  
 >
 Post to : kicad-developers@lists.launchpad.net 
  
 >
 Unsubscribe : https://launchpad.net/~kicad-developers 
  
 >
 More help   : https://help.launchpad.net/ListHelp 
  >
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>  
>>> >> >
>>> Post to : kicad-developers@lists.launchpad.net 
>>>  
>>> >> >
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>  
>>> >> >
>>> More help   : https://help.launchpad.net/ListHelp 
>>>  >> >
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
Hi Orson,

Yes, brew seems to have installed a cairo-quartz.h in 
/usr/local/cellar/cairo/1.16.0/include/cairo/.

Might cmake reference a specific version, or do I need to do something to make 
CMake find it?

Cheers,
Jeff.


> On 2 Nov 2018, at 13:27, Maciej Suminski  wrote:
> 
> Hi Jeff,
> 
> I copied and adjusted your cmake spell, and it works fine for me on
> macOS 10.13 with cairo installed via brew. One difference I spotted is
> that I have cairo_quartz.h in
> /usr/local/Cellar/cairo/1.14.12/include/cairo/.
> 
> Cheers,
> Orson
> 
> On 11/2/18 1:58 PM, Jeff Young wrote:
>> CLion.  CMake args:
>> 
>> -DCMAKE_C_COMPILER=clang
>> -DCMAKE_CXX_COMPILER=clang++
>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
>> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
>> -DKICAD_SCRIPTING=ON
>> -DKICAD_SCRIPTING_MODULES=OFF
>> -DKICAD_SCRIPTING_WXPYTHON=OFF
>> -DKICAD_USE_OCE=OFF
>> -DCMAKE_INSTALL_PREFIX=./bin
>> -DCMAKE_BUILD_TYPE=Debug
>> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 2 Nov 2018, at 12:39, Adam Wolf  wrote:
>>> 
>>> How are you building?  What are your cmake arguments?
>>> 
>>> Adam
>>> 
>>> On Fri, Nov 2, 2018, 7:33 AM Jeff Young >>  > 
>>> wrote:
>>> I also tried “brew install cairo” to no avail.  I assume I need a 
>>> Cairo.framework in my /system/library/frameworks, but I’m not sure how to 
>>> get it there.
>>> 
>>> 
 On 2 Nov 2018, at 10:28, Jeff Young >>>  >> 
 wrote:
 
 "cairo-quartz.h can’t be found”
 
 I have such a file at /opt/local/include/cairo/, but that’s evidently not 
 where the dev system is looking.  Do I need to copy that somewhere, or 
 does something in my setup need to be updated to look for it there?
 
 Thanks,
 Jeff.
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
  
 >
 Post to : kicad-developers@lists.launchpad.net 
  
 >
 Unsubscribe : https://launchpad.net/~kicad-developers 
  
 >
 More help   : https://help.launchpad.net/ListHelp 
  >
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>  
>>> >> >
>>> Post to : kicad-developers@lists.launchpad.net 
>>>  
>>> >> >
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>  
>>> >> >
>>> More help   : https://help.launchpad.net/ListHelp 
>>>  >> >
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Maciej Suminski
Hi Jeff,

I copied and adjusted your cmake spell, and it works fine for me on
macOS 10.13 with cairo installed via brew. One difference I spotted is
that I have cairo_quartz.h in
/usr/local/Cellar/cairo/1.14.12/include/cairo/.

Cheers,
Orson

On 11/2/18 1:58 PM, Jeff Young wrote:
> CLion.  CMake args:
> 
> -DCMAKE_C_COMPILER=clang
> -DCMAKE_CXX_COMPILER=clang++
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
> -DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
> -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=OFF
> -DKICAD_SCRIPTING_WXPYTHON=OFF
> -DKICAD_USE_OCE=OFF
> -DCMAKE_INSTALL_PREFIX=./bin
> -DCMAKE_BUILD_TYPE=Debug
> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
> 
> Cheers,
> Jeff.
> 
> 
>> On 2 Nov 2018, at 12:39, Adam Wolf  wrote:
>>
>> How are you building?  What are your cmake arguments?
>>
>> Adam
>>
>> On Fri, Nov 2, 2018, 7:33 AM Jeff Young >  wrote:
>> I also tried “brew install cairo” to no avail.  I assume I need a 
>> Cairo.framework in my /system/library/frameworks, but I’m not sure how to 
>> get it there.
>>
>>
>>> On 2 Nov 2018, at 10:28, Jeff Young >> > wrote:
>>>
>>> "cairo-quartz.h can’t be found”
>>>
>>> I have such a file at /opt/local/include/cairo/, but that’s evidently not 
>>> where the dev system is looking.  Do I need to copy that somewhere, or does 
>>> something in my setup need to be updated to look for it there?
>>>
>>> Thanks,
>>> Jeff.
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> 
>>> More help   : https://help.launchpad.net/ListHelp 
>>> 
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
CLion.  CMake args:

-DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13
-DwxWidgets_CONFIG_EXECUTABLE=../../wxWidgets/wx-bin/bin/wx-config
-DKICAD_SCRIPTING=ON
-DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
-DKICAD_USE_OCE=OFF
-DCMAKE_INSTALL_PREFIX=./bin
-DCMAKE_BUILD_TYPE=Debug
-DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages

Cheers,
Jeff.


> On 2 Nov 2018, at 12:39, Adam Wolf  wrote:
> 
> How are you building?  What are your cmake arguments?
> 
> Adam
> 
> On Fri, Nov 2, 2018, 7:33 AM Jeff Young   wrote:
> I also tried “brew install cairo” to no avail.  I assume I need a 
> Cairo.framework in my /system/library/frameworks, but I’m not sure how to get 
> it there.
> 
> 
> > On 2 Nov 2018, at 10:28, Jeff Young  > > wrote:
> > 
> > "cairo-quartz.h can’t be found”
> > 
> > I have such a file at /opt/local/include/cairo/, but that’s evidently not 
> > where the dev system is looking.  Do I need to copy that somewhere, or does 
> > something in my setup need to be updated to look for it there?
> > 
> > Thanks,
> > Jeff.
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Adam Wolf
How are you building?  What are your cmake arguments?

Adam

On Fri, Nov 2, 2018, 7:33 AM Jeff Young  I also tried “brew install cairo” to no avail.  I assume I need a
> Cairo.framework in my /system/library/frameworks, but I’m not sure how to
> get it there.
>
>
> > On 2 Nov 2018, at 10:28, Jeff Young  wrote:
> >
> > "cairo-quartz.h can’t be found”
> >
> > I have such a file at /opt/local/include/cairo/, but that’s evidently
> not where the dev system is looking.  Do I need to copy that somewhere, or
> does something in my setup need to be updated to look for it there?
> >
> > Thanks,
> > Jeff.
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
I also tried “brew install cairo” to no avail.  I assume I need a 
Cairo.framework in my /system/library/frameworks, but I’m not sure how to get 
it there.


> On 2 Nov 2018, at 10:28, Jeff Young  wrote:
> 
> "cairo-quartz.h can’t be found”
> 
> I have such a file at /opt/local/include/cairo/, but that’s evidently not 
> where the dev system is looking.  Do I need to copy that somewhere, or does 
> something in my setup need to be updated to look for it there?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure OSX

2018-11-02 Thread Jeff Young
"cairo-quartz.h can’t be found”

I have such a file at /opt/local/include/cairo/, but that’s evidently not where 
the dev system is looking.  Do I need to copy that somewhere, or does something 
in my setup need to be updated to look for it there?

Thanks,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on linux.

2018-07-22 Thread Wayne Stambaugh
Thanks for the quick fix!

On 07/22/2018 06:38 PM, Jeff Young wrote:
> Fix in.
> 
>> On 22 Jul 2018, at 23:33, Jeff Young > > wrote:
>>
>> He he… CLion’s ever-so-helpful automatic #include generator appends
>> them after the last #include…
>>
>> which happens to be inside a #if defined(KICAD_SCRIPTING) block.
>>
>> Fix coming….
>>
>> Cheers,
>> Jeff.
>>
>>
>>> On 22 Jul 2018, at 23:20, Wayne Stambaugh >> > wrote:
>>>
>>> I just pulled the latest changes from the development branch and I'm
>>> getting the following build error on linux:
>>>
>>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp: In member
>>> function ‘void PCB_EDIT_FRAME::OnRunEeschema(wxCommandEvent&)’:
>>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:28: error:
>>> ‘EESCHEMA_EXE’ was not declared in this scope
>>> ExecuteFile( this, EESCHEMA_EXE, filename );
>>>    ^~~~
>>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: error:
>>> ‘ExecuteFile’ was not declared in this scope
>>> ExecuteFile( this, EESCHEMA_EXE, filename );
>>> ^~~
>>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: note:
>>> suggested alternative: ‘wxTextFile’
>>> ExecuteFile( this, EESCHEMA_EXE, filename );
>>> ^~~
>>>
>>> Wayne
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 
>> Post to : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> 
>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on linux.

2018-07-22 Thread Jeff Young
Fix in.

> On 22 Jul 2018, at 23:33, Jeff Young  wrote:
> 
> He he… CLion’s ever-so-helpful automatic #include generator appends them 
> after the last #include…
> 
> which happens to be inside a #if defined(KICAD_SCRIPTING) block.
> 
> Fix coming….
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Jul 2018, at 23:20, Wayne Stambaugh > > wrote:
>> 
>> I just pulled the latest changes from the development branch and I'm
>> getting the following build error on linux:
>> 
>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp: In member
>> function ‘void PCB_EDIT_FRAME::OnRunEeschema(wxCommandEvent&)’:
>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:28: error:
>> ‘EESCHEMA_EXE’ was not declared in this scope
>> ExecuteFile( this, EESCHEMA_EXE, filename );
>>^~~~
>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: error:
>> ‘ExecuteFile’ was not declared in this scope
>> ExecuteFile( this, EESCHEMA_EXE, filename );
>> ^~~
>> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: note:
>> suggested alternative: ‘wxTextFile’
>> ExecuteFile( this, EESCHEMA_EXE, filename );
>> ^~~
>> 
>> Wayne
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure on linux.

2018-07-22 Thread Jeff Young
He he… CLion’s ever-so-helpful automatic #include generator appends them after 
the last #include…

which happens to be inside a #if defined(KICAD_SCRIPTING) block.

Fix coming….

Cheers,
Jeff.


> On 22 Jul 2018, at 23:20, Wayne Stambaugh  wrote:
> 
> I just pulled the latest changes from the development branch and I'm
> getting the following build error on linux:
> 
> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp: In member
> function ‘void PCB_EDIT_FRAME::OnRunEeschema(wxCommandEvent&)’:
> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:28: error:
> ‘EESCHEMA_EXE’ was not declared in this scope
> ExecuteFile( this, EESCHEMA_EXE, filename );
>^~~~
> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: error:
> ‘ExecuteFile’ was not declared in this scope
> ExecuteFile( this, EESCHEMA_EXE, filename );
> ^~~
> /home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: note:
> suggested alternative: ‘wxTextFile’
> ExecuteFile( this, EESCHEMA_EXE, filename );
> ^~~
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure on linux.

2018-07-22 Thread Wayne Stambaugh
I just pulled the latest changes from the development branch and I'm
getting the following build error on linux:

/home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp: In member
function ‘void PCB_EDIT_FRAME::OnRunEeschema(wxCommandEvent&)’:
/home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:28: error:
‘EESCHEMA_EXE’ was not declared in this scope
 ExecuteFile( this, EESCHEMA_EXE, filename );
^~~~
/home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: error:
‘ExecuteFile’ was not declared in this scope
 ExecuteFile( this, EESCHEMA_EXE, filename );
 ^~~
/home/wayne/src/kicad-trunk/pcbnew/pcb_edit_frame.cpp:1253:9: note:
suggested alternative: ‘wxTextFile’
 ExecuteFile( this, EESCHEMA_EXE, filename );
 ^~~

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure?

2018-07-20 Thread Jeff Young
Yep, that works on Mac too.  Thanks for tracking that down.

(And a cache flush of my IDE appears to have fixed the other problem.)

Cheers,
Jeff.


> On 20 Jul 2018, at 19:32, Seth Hillbrand  wrote:
> 
> Looking at it, the file includes .  I think you wanted 
>   Does that work on Mac?
> 
> -S
> 
> Am Fr., 20. Juli 2018 um 11:28 Uhr schrieb Jeff Young  >:
> Hi Seth,
> 
> That looks different.  Is wxComboCtrl not implemented on Linux?  (Or perhaps 
> it has a different header file?)
> 
> Cheers,
> 
> Jeff.
> 
>> On 20 Jul 2018, at 19:25, Seth Hillbrand > > wrote:
>> 
>> Hi Jeff-
>> 
>> I get a build failure here (Linux):
>> 
>> In file included from 
>> /home/seth/code/kicad/kicad-launchpad/eeschema/fields_grid_table.cpp:34:0:
>> /home/seth/code/kicad/kicad-launchpad/include/widgets/grid_text_button_helpers.h:51:5:
>>  error: ‘wxComboCtrl’ does not name a type
>>  wxComboCtrl* Combo() const { return static_cast( 
>> m_control ); }
>> 
>> -S
>> 
>> Am Fr., 20. Juli 2018 um 11:11 Uhr schrieb Jeff Young > >:
>> I just merged out and my build now fails trying to link the Eagle plugin 
>> test.
>> 
>> But I can’t find any commits that have anything to do with that (in fact I 
>> should have only picked up one commit, which is completely unrelated).
>> 
>> Anyone else seeing this?
>> 
>> Cheers,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure?

2018-07-20 Thread Seth Hillbrand
Looking at it, the file includes .  I think you wanted
  Does that work on Mac?

-S

Am Fr., 20. Juli 2018 um 11:28 Uhr schrieb Jeff Young :

> Hi Seth,
>
> That looks different.  Is wxComboCtrl not implemented on Linux?  (Or
> perhaps it has a different header file?)
>
> Cheers,
>
> Jeff.
>
> On 20 Jul 2018, at 19:25, Seth Hillbrand  wrote:
>
> Hi Jeff-
>
> I get a build failure here (Linux):
>
> In file included from
> /home/seth/code/kicad/kicad-launchpad/eeschema/fields_grid_table.cpp:34:0:
> /home/seth/code/kicad/kicad-launchpad/include/widgets/grid_text_button_helpers.h:51:5:
> error: ‘wxComboCtrl’ does not name a type
>  wxComboCtrl* Combo() const { return static_cast(
> m_control ); }
>
> -S
>
> Am Fr., 20. Juli 2018 um 11:11 Uhr schrieb Jeff Young :
>
>> I just merged out and my build now fails trying to link the Eagle plugin
>> test.
>>
>> But I can’t find any commits that have anything to do with that (in fact
>> I should have only picked up one commit, which is completely unrelated).
>>
>> Anyone else seeing this?
>>
>> Cheers,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure?

2018-07-20 Thread Jeff Young
Hi Seth,

That looks different.  Is wxComboCtrl not implemented on Linux?  (Or perhaps it 
has a different header file?)

Cheers,

Jeff.

> On 20 Jul 2018, at 19:25, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> I get a build failure here (Linux):
> 
> In file included from 
> /home/seth/code/kicad/kicad-launchpad/eeschema/fields_grid_table.cpp:34:0:
> /home/seth/code/kicad/kicad-launchpad/include/widgets/grid_text_button_helpers.h:51:5:
>  error: ‘wxComboCtrl’ does not name a type
>  wxComboCtrl* Combo() const { return static_cast( m_control 
> ); }
> 
> -S
> 
> Am Fr., 20. Juli 2018 um 11:11 Uhr schrieb Jeff Young  >:
> I just merged out and my build now fails trying to link the Eagle plugin test.
> 
> But I can’t find any commits that have anything to do with that (in fact I 
> should have only picked up one commit, which is completely unrelated).
> 
> Anyone else seeing this?
> 
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure?

2018-07-20 Thread Seth Hillbrand
Hi Jeff-

I get a build failure here (Linux):

In file included from
/home/seth/code/kicad/kicad-launchpad/eeschema/fields_grid_table.cpp:34:0:
/home/seth/code/kicad/kicad-launchpad/include/widgets/grid_text_button_helpers.h:51:5:
error: ‘wxComboCtrl’ does not name a type
 wxComboCtrl* Combo() const { return static_cast(
m_control ); }

-S

Am Fr., 20. Juli 2018 um 11:11 Uhr schrieb Jeff Young :

> I just merged out and my build now fails trying to link the Eagle plugin
> test.
>
> But I can’t find any commits that have anything to do with that (in fact I
> should have only picked up one commit, which is completely unrelated).
>
> Anyone else seeing this?
>
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure w.r.t. wxDateTime

2018-03-29 Thread Seth Hillbrand
Hi Thomas-

Your analysis is correct.  m_LastEditTime was recently changed to
timestamp_t but holds time_t information and (for now) can be safely cast.

I've pushed an update, let me know if it's still problematic.

-S

(Sorry for the double-email.)

2018-03-29 9:14 GMT-07:00 Thomas Figueroa :

> I recently started getting a “Call of overloaded
> 'wxDateTime(timestamp_t&)' is ambiguous” compilation failure
>
> in class_module.cpp line 573. I modified it to static_cast
> m_LastEditTime, but I’m not sure that is
>
> what is intended here. This occurs both on MSVC and MSYS2 builds.
>
> (MSYS2 build here: http://darine.hogyros.de:8080/
> job/windows-kicad-msys2/244/)
>
>
>
> Thomas
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure w.r.t. wxDateTime

2018-03-29 Thread Thomas Figueroa
I recently started getting a "Call of overloaded 'wxDateTime(timestamp_t&)' is 
ambiguous" compilation failure
in class_module.cpp line 573. I modified it to static_cast 
m_LastEditTime, but I'm not sure that is
what is intended here. This occurs both on MSVC and MSYS2 builds.
(MSYS2 build here: http://darine.hogyros.de:8080/job/windows-kicad-msys2/244/)

Thomas
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure

2018-03-23 Thread Bernhard Stegmaier
First thing I did with QTCreator is to delete all of the default 
(build/release/etc) build configurations that it sets up when 
creating/importing a project.
Then, I created my own one with the settings I need for KiCad (especially build 
options and paths).
I didn’t have any problems since then.

I can send you my configuration later on, maybe it helps…


Regards,
Bernhard

> On 23. Mar 2018, at 01:33, Jeff Young  wrote:
> 
> Based on Seth’s "cache cruft" comment I whacked my CMakeCache.txt entirely, 
> and my cmd-line build is running again from kicad/build/.  
> 
> I’m afraid to run QTCreator again, though.
> 
>> On 23 Mar 2018, at 00:20, Jeff Young > > wrote:
>> 
>> I think used to do a “make install” inside kicad/build/.  But now it says it 
>> doesn’t have an install target.  (And if I do a “make” that’s when I get the 
>> OCE errors.)
>> 
>> “make install” works one level higher (in kicad/), but then spews out a 
>> whole bunch of CMakeFiles directories as siblings to build/ which pollute my 
>> git status.
>> 
>> 
>> 
>>> On 23 Mar 2018, at 00:14, Jeff Young >> > wrote:
>>> 
>>> It complains that it doesn’t have a CMake dialog available.
>>> 
>>> Could someone dump in their cmake command (and indicate what directory it 
>>> is executed from)?
>>> 
>>> Thanks
>>> Jeff.
>>> 
>>> 
 On 22 Mar 2018, at 23:32, Seth Hillbrand > wrote:
 
 Hi Jeff-
 
 I assume you have a populated cmake build directory.  If so, you can run 
 "make edit_cache" and you should be see what is toggled on and off and 
 adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.  
 You can also delete cache entries using this tool, in case there is cruft 
 from a previous config.
 
 You should only see that message if cmake thinks you are trying to enable 
 OCE.  I don't see any recent changes that would have affected this option. 
 (my OpenCascade patch is not in the tree yet)
 
 -S
 
 2018-03-22 16:20 GMT-07:00 Jeff Young >:
 No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something 
 I would have had to install?
 
 I’m not sure what’s different.  I was trying to get it to build with 
 scripting on and the wheels came off…
 
 Cheers,
 Jeff.
 
 
> On 22 Mar 2018, at 23:09, Nick Østergaard  > wrote:
> 
> Do you have Seth's opencascade patch in your tree? Or what is different 
> from the usual? The build flag you are specifying shoulnd be correct IIRC.
> 
> 2018-03-22 23:56 GMT+01:00 Jeff Young  >:
> What does this mean:
> 
> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "OCE", but
> CMake did not find one.
> 
> Could not find a package configuration file provided by "OCE" (requested
> version 0.16) with any of the following names:
> 
> OCEConfig.cmake
> oce-config.cmake
> 
> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
> to a directory containing one of the above files. If "OCE" provides a
> separate development package or SDK, be sure it has been installed.
> 
> I thought I had avoided this stuff by specifying:
> 
> -DKICAD_USE_OCE=OFF \
> 
> but it seems to be back.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 Unsubscribe : https://launchpad.net/~kicad-developers 
 
 More help   : https://help.launchpad.net/ListHelp 
 
 
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers 

Re: [Kicad-developers] Build failure

2018-03-22 Thread Jeff Young
Based on Seth’s "cache cruft" comment I whacked my CMakeCache.txt entirely, and 
my cmd-line build is running again from kicad/build/.  

I’m afraid to run QTCreator again, though.

> On 23 Mar 2018, at 00:20, Jeff Young  wrote:
> 
> I think used to do a “make install” inside kicad/build/.  But now it says it 
> doesn’t have an install target.  (And if I do a “make” that’s when I get the 
> OCE errors.)
> 
> “make install” works one level higher (in kicad/), but then spews out a whole 
> bunch of CMakeFiles directories as siblings to build/ which pollute my git 
> status.
> 
> 
> 
>> On 23 Mar 2018, at 00:14, Jeff Young > > wrote:
>> 
>> It complains that it doesn’t have a CMake dialog available.
>> 
>> Could someone dump in their cmake command (and indicate what directory it is 
>> executed from)?
>> 
>> Thanks
>> Jeff.
>> 
>> 
>>> On 22 Mar 2018, at 23:32, Seth Hillbrand >> > wrote:
>>> 
>>> Hi Jeff-
>>> 
>>> I assume you have a populated cmake build directory.  If so, you can run 
>>> "make edit_cache" and you should be see what is toggled on and off and 
>>> adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.  
>>> You can also delete cache entries using this tool, in case there is cruft 
>>> from a previous config.
>>> 
>>> You should only see that message if cmake thinks you are trying to enable 
>>> OCE.  I don't see any recent changes that would have affected this option. 
>>> (my OpenCascade patch is not in the tree yet)
>>> 
>>> -S
>>> 
>>> 2018-03-22 16:20 GMT-07:00 Jeff Young >> >:
>>> No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something I 
>>> would have had to install?
>>> 
>>> I’m not sure what’s different.  I was trying to get it to build with 
>>> scripting on and the wheels came off…
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 22 Mar 2018, at 23:09, Nick Østergaard > wrote:
 
 Do you have Seth's opencascade patch in your tree? Or what is different 
 from the usual? The build flag you are specifying shoulnd be correct IIRC.
 
 2018-03-22 23:56 GMT+01:00 Jeff Young >:
 What does this mean:
 
 By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
 asked CMake to find a package configuration file provided by "OCE", but
 CMake did not find one.
 
 Could not find a package configuration file provided by "OCE" (requested
 version 0.16) with any of the following names:
 
 OCEConfig.cmake
 oce-config.cmake
 
 Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
 to a directory containing one of the above files. If "OCE" provides a
 separate development package or SDK, be sure it has been installed.
 
 I thought I had avoided this stuff by specifying:
 
 -DKICAD_USE_OCE=OFF \
 
 but it seems to be back.
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 Unsubscribe : https://launchpad.net/~kicad-developers 
 
 More help   : https://help.launchpad.net/ListHelp 
 
 
 
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> 
>>> More help   : https://help.launchpad.net/ListHelp 
>>> 
>>> 
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : 

Re: [Kicad-developers] Build failure

2018-03-22 Thread Jeff Young
I think used to do a “make install” inside kicad/build/.  But now it says it 
doesn’t have an install target.  (And if I do a “make” that’s when I get the 
OCE errors.)

“make install” works one level higher (in kicad/), but then spews out a whole 
bunch of CMakeFiles directories as siblings to build/ which pollute my git 
status.



> On 23 Mar 2018, at 00:14, Jeff Young  wrote:
> 
> It complains that it doesn’t have a CMake dialog available.
> 
> Could someone dump in their cmake command (and indicate what directory it is 
> executed from)?
> 
> Thanks
> Jeff.
> 
> 
>> On 22 Mar 2018, at 23:32, Seth Hillbrand > > wrote:
>> 
>> Hi Jeff-
>> 
>> I assume you have a populated cmake build directory.  If so, you can run 
>> "make edit_cache" and you should be see what is toggled on and off and 
>> adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.  
>> You can also delete cache entries using this tool, in case there is cruft 
>> from a previous config.
>> 
>> You should only see that message if cmake thinks you are trying to enable 
>> OCE.  I don't see any recent changes that would have affected this option. 
>> (my OpenCascade patch is not in the tree yet)
>> 
>> -S
>> 
>> 2018-03-22 16:20 GMT-07:00 Jeff Young > >:
>> No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something I 
>> would have had to install?
>> 
>> I’m not sure what’s different.  I was trying to get it to build with 
>> scripting on and the wheels came off…
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 22 Mar 2018, at 23:09, Nick Østergaard >> > wrote:
>>> 
>>> Do you have Seth's opencascade patch in your tree? Or what is different 
>>> from the usual? The build flag you are specifying shoulnd be correct IIRC.
>>> 
>>> 2018-03-22 23:56 GMT+01:00 Jeff Young >> >:
>>> What does this mean:
>>> 
>>> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
>>> asked CMake to find a package configuration file provided by "OCE", but
>>> CMake did not find one.
>>> 
>>> Could not find a package configuration file provided by "OCE" (requested
>>> version 0.16) with any of the following names:
>>> 
>>> OCEConfig.cmake
>>> oce-config.cmake
>>> 
>>> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
>>> to a directory containing one of the above files. If "OCE" provides a
>>> separate development package or SDK, be sure it has been installed.
>>> 
>>> I thought I had avoided this stuff by specifying:
>>> 
>>> -DKICAD_USE_OCE=OFF \
>>> 
>>> but it seems to be back.
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>> Post to : kicad-developers@lists.launchpad.net 
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> 
>>> More help   : https://help.launchpad.net/ListHelp 
>>> 
>>> 
>>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure

2018-03-22 Thread Jeff Young
It complains that it doesn’t have a CMake dialog available.

Could someone dump in their cmake command (and indicate what directory it is 
executed from)?

Thanks
Jeff.


> On 22 Mar 2018, at 23:32, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> I assume you have a populated cmake build directory.  If so, you can run 
> "make edit_cache" and you should be see what is toggled on and off and 
> adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.  You 
> can also delete cache entries using this tool, in case there is cruft from a 
> previous config.
> 
> You should only see that message if cmake thinks you are trying to enable 
> OCE.  I don't see any recent changes that would have affected this option. 
> (my OpenCascade patch is not in the tree yet)
> 
> -S
> 
> 2018-03-22 16:20 GMT-07:00 Jeff Young  >:
> No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something I 
> would have had to install?
> 
> I’m not sure what’s different.  I was trying to get it to build with 
> scripting on and the wheels came off…
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Mar 2018, at 23:09, Nick Østergaard > > wrote:
>> 
>> Do you have Seth's opencascade patch in your tree? Or what is different from 
>> the usual? The build flag you are specifying shoulnd be correct IIRC.
>> 
>> 2018-03-22 23:56 GMT+01:00 Jeff Young > >:
>> What does this mean:
>> 
>> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
>> asked CMake to find a package configuration file provided by "OCE", but
>> CMake did not find one.
>> 
>> Could not find a package configuration file provided by "OCE" (requested
>> version 0.16) with any of the following names:
>> 
>> OCEConfig.cmake
>> oce-config.cmake
>> 
>> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
>> to a directory containing one of the above files. If "OCE" provides a
>> separate development package or SDK, be sure it has been installed.
>> 
>> I thought I had avoided this stuff by specifying:
>> 
>> -DKICAD_USE_OCE=OFF \
>> 
>> but it seems to be back.
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure

2018-03-22 Thread Seth Hillbrand
Hi Jeff-

I assume you have a populated cmake build directory.  If so, you can run
"make edit_cache" and you should be see what is toggled on and off and
adjust.  Then hit "c" to reconfigure and "g" to generate your makefiles.
You can also delete cache entries using this tool, in case there is cruft
from a previous config.

You should only see that message if cmake thinks you are trying to enable
OCE.  I don't see any recent changes that would have affected this option.
(my OpenCascade patch is not in the tree yet)

-S

2018-03-22 16:20 GMT-07:00 Jeff Young :

> No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something
> I would have had to install?
>
> I’m not sure what’s different.  I was trying to get it to build with
> scripting on and the wheels came off…
>
> Cheers,
> Jeff.
>
>
> On 22 Mar 2018, at 23:09, Nick Østergaard  wrote:
>
> Do you have Seth's opencascade patch in your tree? Or what is different
> from the usual? The build flag you are specifying shoulnd be correct IIRC.
>
> 2018-03-22 23:56 GMT+01:00 Jeff Young :
>
>> What does this mean:
>>
>> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
>> asked CMake to find a package configuration file provided by "OCE", but
>> CMake did not find one.
>>
>> Could not find a package configuration file provided by "OCE" (requested
>> version 0.16) with any of the following names:
>>
>> OCEConfig.cmake
>> oce-config.cmake
>>
>> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
>> to a directory containing one of the above files. If "OCE" provides a
>> separate development package or SDK, be sure it has been installed.
>>
>>
>> I thought I had avoided this stuff by specifying:
>>
>> -DKICAD_USE_OCE=OFF \
>>
>> but it seems to be back.
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure

2018-03-22 Thread Jeff Young
No, I don’t have Seth’s patch (to my knowledge).  I assume it’s something I 
would have had to install?

I’m not sure what’s different.  I was trying to get it to build with scripting 
on and the wheels came off…

Cheers,
Jeff.


> On 22 Mar 2018, at 23:09, Nick Østergaard  wrote:
> 
> Do you have Seth's opencascade patch in your tree? Or what is different from 
> the usual? The build flag you are specifying shoulnd be correct IIRC.
> 
> 2018-03-22 23:56 GMT+01:00 Jeff Young  >:
> What does this mean:
> 
> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "OCE", but
> CMake did not find one.
> 
> Could not find a package configuration file provided by "OCE" (requested
> version 0.16) with any of the following names:
> 
> OCEConfig.cmake
> oce-config.cmake
> 
> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
> to a directory containing one of the above files. If "OCE" provides a
> separate development package or SDK, be sure it has been installed.
> 
> I thought I had avoided this stuff by specifying:
> 
> -DKICAD_USE_OCE=OFF \
> 
> but it seems to be back.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure

2018-03-22 Thread Nick Østergaard
Do you have Seth's opencascade patch in your tree? Or what is different
from the usual? The build flag you are specifying shoulnd be correct IIRC.

2018-03-22 23:56 GMT+01:00 Jeff Young :

> What does this mean:
>
> By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "OCE", but
> CMake did not find one.
>
> Could not find a package configuration file provided by "OCE" (requested
> version 0.16) with any of the following names:
>
> OCEConfig.cmake
> oce-config.cmake
>
> Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
> to a directory containing one of the above files. If "OCE" provides a
> separate development package or SDK, be sure it has been installed.
>
>
> I thought I had avoided this stuff by specifying:
>
> -DKICAD_USE_OCE=OFF \
>
> but it seems to be back.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure

2018-03-22 Thread Jeff Young
What does this mean:

By not providing "FindOCE.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "OCE", but
CMake did not find one.

Could not find a package configuration file provided by "OCE" (requested
version 0.16) with any of the following names:

OCEConfig.cmake
oce-config.cmake

Add the installation prefix of "OCE" to CMAKE_PREFIX_PATH or set "OCE_DIR"
to a directory containing one of the above files. If "OCE" provides a
separate development package or SDK, be sure it has been installed.

I thought I had avoided this stuff by specifying:

-DKICAD_USE_OCE=OFF \

but it seems to be back.___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp