kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

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