On 8/16/2014 6:22 PM, Cirilo Bernardo wrote: > ----- Original Message ----- > >> From: Wayne Stambaugh <stambau...@verizon.net> >> To: KiCad Developers <kicad-developers@lists.launchpad.net> >> Cc: >> Sent: Sunday, August 17, 2014 2:44 AM >> Subject: [Kicad-developers] KiCad build. >> >> One of the tasks that I have committed to working on in the KiCad road >> map is to clean up the current mess we have created by allowing >> dependency libraries to be built as part of the KiCad source build. The >> only exception I see for the time being is Boost. Although I am have my >> reservations on that as well. Why you ask? I've spent several days >> trying to get KiCad to build on Windows using MSYS2 as my build >> environment and mingw64 as my target environment. Every single library >> dependency with the exception of our custom Boost and avhttp (which >> could easily be build and installed using CMake) are already packaged >> for me. However, the current KiCad build insists on downloading and >> building some libraries from source that are already installed. This is >> silly. I can resolve the issues by passing all of the >> PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my >> build environment already points the correct path. >> >> Originally I intended to create a separate project to build the KiCad >> library dependencies but I have since changed my mind. I do *not* think >> it is asking too much of developers to learn how to build and/or install >> libraries on their preferred platform. If as a developer you must have >> this done for you automatically, I am going to please ask that *you* >> create a separate platform specific build tool such as the excellent >> kicad-winbuilder that Brian has created. This will significantly >> simplify the KiCad CMake files and eliminate the situation I described >> above. My preference and goal is that the KiCad CMake files be used to >> build KiCad, not library dependencies. >> >> Initially, I plan to remove the dependencies that do not require any >> patching to build which currently are avhttp, swig, cairo, libpng, >> pixman, pcre, pkgconfig, and glew. Then I will remove the dependencies >> with platform specific patches which are openssl, wxwidgets and >> wxpython. Then I will try to figure out what to do with the problem >> child that is Boost. I would also suggest that all platform specific >> library dependency build patches be remove as well leaving only the >> Boost patches that are required for all platforms (except the context >> switching patches). >> >> My goal here is not to step on anyone's toes it is to get our build >> system under control so that I can build *KiCad* rather than figure out >> how to get the dependencies to build or not as the platform dictates. I >> expect our code to be well designed and I don't think expecting the same >> from our build system design is out of line. If any one has major >> objections then we will have to figure something out because I am not >> going to continue to spend valuable time fighting our build tools to get >> them to properly use the dependencies already installed on my platform. >> >> Wayne >> > > > No objections at all here. I agree with Dick that this will probably > hurt MacOSX users the most.
I would hope it wouldn't be an issue for users as much as for developers. We really need to get to the point where we can provide nightly builds (or at least current builds) of OSX and Windows. > > Personally I wouldn't mind seeing libdxf ripped out either unless there > are some KiCad specific changes in there which prevent us from using the > stock library. I can check this out on my system in about a week's time; > I'll attempt to link the DXF importer and DXF/IDF tools to > libdxflib-2.5.0.0 and see what breaks. Thanks for looking at this. JP can probably add some insight as to whether or not he had to make any changes to libdxf to work with KiCad. Out of curiosity, what build system does libdxf use? As long as its autoconf or CMake, there should be no problems building it on all platforms. > > As for devs, for the most part I think issues will be solved by running > ldd on the executables, writing up a requirements list and updating the > web page. All Linux distributions will have a slightly different way of > dealing with things but generally there should be no problems and > package maintainers will have an easier life with the changes. OSX and > MSWin users will have to work out the necessary voodoo for their own > systems and update documentation or platform-specific build instructions. There are build instructions in the documentation folder in the Kicad source but I think they are very much out of date. At some point I would like to update them and convert them to mark down and built into the current developers documentation so that all of the developers documentation are in one place. > > - Cirilo > > _______________________________________________ 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
