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 <bobgus@xxxxxxx
<mailto:bobgus@xxxxxxx>> 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
<stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>> 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 <bobgus@xxxxxxx
<mailto:bobgus@xxxxxxx>> 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
<https://launchpad.net/%7Ekicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
