kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

No problem, have a good one.

Adam Wolf
Cofounder and Engineer
W&L

On Sun, Feb 22, 2015 at 5:10 PM, Bob Gustafson <bobgus@xxxxxxx> 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 <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
>>>
>>
>>
>>
>
>