No problem, have a good one. Adam Wolf Cofounder and Engineer W&L
On Sun, Feb 22, 2015 at 5:10 PM, Bob Gustafson <[email protected]> wrote: > Yes, all great reasons/comments. Time is indeed a scarce commodity. > > Fun, and feedback from your grateful users and testers are the only offset > for your time. > > Thanks very much. > > Bob G :-) > > > On 02/22/2015 05:02 PM, Adam Wolf wrote: > > 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
