On 8/16/2014 8:41 PM, Michael Narigon wrote: > It appears that I can push the files to launchpad. I will make sure the Linux > version builds and load it up so you can look at it to see if it is useful. > Michael
Thanks. I'll take a look at it once you push it to launchpad. Please post the repo name once you get it pushed. Maybe the folks who are working on auto builders can take a look at it and see if there is anything that would be helpful to them as well. > > On Aug 16, 2014, at 5:15 PM, Wayne Stambaugh <stambau...@verizon.net> wrote: > >> On 8/16/2014 6:28 PM, Michael Narigon wrote: >>> All, >>> I am actually pretty far along with this separation of build. Is there a >>> recommended location I could post some files so you could see how I >>> approached it? I basically expanded the kicad-install.sh script with >>> additional steps. One of the main things I do is I work with completely >>> clean setups in virtual machines. That lets me check for dependencies that >>> the average user might not have installed. I am furthest along on OS X (I >>> am working out how to build a signed, drag and drop package containing all >>> of the new modular programs.) I have it working on Linux although I do not >>> have the Debian and RPM installers running yet. I am furthest from >>> finishing on Windows. >> >> Feel free to post them to the mailing list so other developers can take >> a look at them. I prefer your build script solution what we are >> currently doing. If they prove to be useful, we could include them with >> the other scripts that we provide. If you have a nearly complete OSX >> solution, I'm sure our OSX developers would like to take a look at what >> you've done so far because they will be impacted the most by the changes >> I am going to make. Maybe your build scripts will help ease the >> transition. If you've modified any CMake files, please post the diffs >> so I can see what you've changed and what impact the changes I am >> planning to make will effect what you've done so far. >> >> Thanks, >> >> Wayne >> >>> >>> Michael >>> >>> On Aug 16, 2014, at 3:11 PM, Wayne Stambaugh <stambau...@verizon.net> wrote: >>> >>>> On 8/16/2014 3:07 PM, Jason Whiteman wrote: >>>>> I'm not sure if I'm in the minority - but I have deferred work due to >>>>> build issues with the dependencies. I'm capable of sorting this out >>>>> myself - but wasn't willing to invest the time beyond what I had already >>>>> invested in order to move forward. Your decoupling will lead to more >>>>> burden on the developer for builds -- but perhaps the new structure will >>>>> eventually change the paradigm and allow for easier management of >>>>> platform-specific build requirements. >>>>> >>>>> Thumbs up on any work to arrive at this goal. >>>> >>>> That is one of the goals. The current situation contains a bunch of >>>> platform specific checks which break on other platforms or cross builds. >>>> This in and of itself is just plain wrong and probably what you have >>>> been experiencing. I know that it has been a thorn in my side for some >>>> time now. Testing for platforms in build tools be it CMake, autoconf, >>>> scons, etc. is broken by design. The general rule of thumb for >>>> configuration tools is test for features not platforms. If you don't >>>> understand how to configure you platform to build KiCad, it is your >>>> responsibility as a developer to correct and should not be part of the >>>> build configuration of KiCad. While I can sympathize with the plight of >>>> inexperienced developers, the only thing the KiCad build configuration >>>> should do is make sure you have the appropriate dependencies installed >>>> on your platform to build KiCad. >>>> >>>>> >>>>> Regards, >>>>> Jason >>>>> >>>>> >>>>> >>>>> On Sat, Aug 16, 2014 at 11:44 AM, Wayne Stambaugh >>>>> <stambau...@verizon.net <mailto:stambau...@verizon.net>> wrote: >>>>> >>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> <mailto: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