1) Nightly builds are going to *always* use the current revno. It doesn't make sense to do anything else. I don't even have a way to do it any differently. 2) Yes, the builds are completely automated, but supporting users isn't, and either is writing emails for this dev list. 3) There are a lot of CMake switches. Thinking of how many you have "on" vs. "off" is a non-starter. If you mean features, which features besides Python scripting aren't enabled that you're looking for? 4) Feel free to change it. If you get it tested and it works great, I might be able to switch over to it, as long as it supports easy addition and removal of patches against wx by just adding a patch to a local directory--i.e. not one in the kicad tree. You may want to wait until I outline the changes I'll be making to the scripts, or until I document it. Up to you.
Adam Wolf Cofounder and Engineer W&L On Sun, Feb 22, 2015 at 4:52 PM, Bob Gustafson <[email protected]> wrote: > > On 02/22/2015 03:44 PM, Adam Wolf wrote: > > Any patches in my nightlies against kicad are for packaging purposes > only. I do not believe there are any now. This is why, for example, I did > not include the trackpad support in the nightlies, even though I run it on > all my personal builds. > > (Will it be easy for me to *also* provide a trackpad branch? Yes, but > nightlies are only a few days old, and I need a little break :) ) > > > Yes, thanks much for your efforts to bring the OSX platform up to the > level of Linux and Windows. It is not an easy job and you have been > miraculously diligent. > > > With regards to boost--I have no idea why people want to run on a newer > point release of boost on KiCad, especially on Mac. I remember the bug > reports, years ago, of super weird behavior due to issues in boost, and the > complicated efforts it took to isolate the issue to boost, and to fix > them. It isn't like we're using an ancient version of boost or anything, > either. > > > I think the need for 1.57.0 was to support the python scripting. I may be > wrong about this - haven't clicked through the emails on that. > > > The fact that we're still getting weird bug reports (like the one today > or yesterday) makes me want to be *more* conservative with my nightlies, > not less. > > Perhaps a conservative approach would not show the problems. I'm assuming > that by conservative you mean using a lower revno, or less switches 'on'. > > New test builds should show new problems (assuming that the old problems > have been fixed). > > A failing build image is a motivation! > > > Every minute I spend on support is a minute I'm not writing new features > (like a default fp-table-lib selector so users who want to use a "normal" > configuration will be able to use them without copying files around), > helping get features other people wrote ready to merge into master (like > the trackpad support), enhancing the nightlies, (adding python scripting > support, adding a build.log in the dmg, or providing a changelog that shows > a list of commit messages between each night's versions), or working on > automated testing to help maintain or even increase the quality of KiCad. > > > Yes, of course - but you now have the nightlies automated, yes? Automation > means no thought required... :-) > > > There's no magic about the builds, by the way--every night, around > midnight CST, they basically check out the latest source, and run through > the mac-osx compiling document. I use my own wx compiler script, but it > basically does the same as the one in the tree--I just wrote mine before > there was one in the tree. > > The scripts are available here: > https://code.launchpad.net/~adamwolf/+junk/kicad-mac-packaging > <https://code.launchpad.net/%7Eadamwolf/+junk/kicad-mac-packaging> I'm > not really happy with them, and I want to rewrite most of them, but doing > that is relatively low on my list. I also haven't really publicized these, > because I'm worried people will use them as general purpose OS X builders, > and there's some optimizations and tradeoffs made in order to make it easy > to integrate into the Wayne and Layne build cluster. It works on a regular > system, mostly, but any existing documentation on it currently assumes you > know what you're doing, mostly. :) > > I would prefer that the tree script be used, but I haven't compared the > two to see if it matters at all. > > > Adam Wolf > Cofounder and Engineer > Wayne and Layne, LLC > > On Sun, Feb 22, 2015 at 1:38 PM, Bernhard Stegmaier < > [email protected]> wrote: > >> Well, I think the point is to have KiCad at bleeding edge, but not every >> dependency library. >> As long as there are no known issues with an old boost, et. al., why >> should you want to be also at bleeding edge of those? >> >> Updating everything frequently just makes it harder to see if issues are >> in KiCad or in an updated dependency. >> >> And wrt to features Adam already told that he will be working on >> providing a scripting enabled build next. >> >> >> Regards, >> Bernhard >> >> > On 22 Feb 2015, at 20:31, Bob Gustafson <[email protected]> wrote: >> > >> > I am thinking that the point of 'Nightlies' is to build at the >> 'bleeding edge' and provide the builds to folks who can then easily try >> their normal working 'use case' to see if things (still) work. If they >> crash - fine, we have a data point. >> > >> > Looking at the Version info of the current 'Nightlies', I see boost >> still at 1.54, and many of the environmental variables turned 'off'. The >> source code version does seem pretty close to the repository revno, but do >> the added patches affect things that are not turned 'on' by the environment >> variables? >> > >> > Just a thought. >> > >> > Bob G >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
