kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Why don't you target a git or bzr tag--probably easier to reuse the work
for a "nightlies/fresh" ebuild as well.

Adam Wolf

On Tue, Sep 8, 2015 at 12:37 PM, Ian Woloschin <ian@xxxxxxxxxxxxx> wrote:

> Hooray for already solved problems!  :D  Too bad the baby is still
> sleeping.  Time for new things to solve!
>
> For the Gentoo ebuild, will the project consider releasing a source
> tarball, or is it just going to be a bzr (...git?) tag in the appropriate
> repository?  I don't think it matters, I believe ebuilds can pull straight
> from repositories, but it'd be helpful to know what to target.
>
> -Ian
>
> On Tue, Sep 8, 2015 at 1:33 PM Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
> wrote:
>
>> Ian, I think you are right.  I think everything is already done, except
>> me putting the "issue a PR" into Jenkins so it happens periodically.
>>
>> Adam Wolf
>>
>>
>> On Tue, Sep 8, 2015 at 12:31 PM, Ian Woloschin <ian@xxxxxxxxxxxxx> wrote:
>>
>>> I think that there should be an easy to grab DMG that can be installed,
>>> but it appears to be trivial to use homebrew casks to "automate" the
>>> process.  Keep in mind, casks are *not* compiling anything, they're just
>>> grabbing pre-existing binaries because it makes it "easier" (for CLI folk)
>>> to install packages.  Biggest benefit is versioning should be automatic, so
>>> long as someone here can commit to also releasing a new cask, but that
>>> looks like a pretty simple process (though it does add "just one more
>>> thing" to the list, which may be undesirable).
>>>
>>> I'm going to leave the current homebrew cask stuff alone for now since I
>>> believe it works "as is" and just needs to be updated once we have a RC DMG.
>>>
>>> Going to take a look at Gentoo ebuilds this afternoon I think.  This
>>> might be tough without a tagged release, but I'll see what I can do.
>>>
>>> -Ian
>>>
>>> On Tue, Sep 8, 2015 at 1:22 PM Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>
>>>> The DMGs are not going away and are the primary method for KiCad on OS
>>>> X.
>>>>
>>>> I'm not going to spend my limited time supporting folks who want to
>>>> compile KiCad on their own on OS X, but I'm also not going to hide or
>>>> obsfucate any of the helper scripts I use to build it.
>>>>
>>>> On the other hand, it looks like someone else has made a homebrew cask
>>>> thing that pulls from the DMGs, which is pretty slick.
>>>>
>>>> Adam Wolf
>>>> Cofounder and Engineer
>>>> Wayne and Layne
>>>>
>>>> On Tue, Sep 8, 2015 at 12:12 PM, Andy Peters <devel@xxxxxxxxx> wrote:
>>>>
>>>>>
>>>>> > On Sep 7, 2015, at 9:13 AM, Bernhard Stegmaier <
>>>>> stegmaier@xxxxxxxxxxxxx> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > a small note on homebrew (or, MacPorts) for OS X:
>>>>> > The problem is, that you need a special patched wxWidgets for KiCad.
>>>>> > So, you can’t (no, you can’t) use the stock one such a package
>>>>> system provides - and you probably cannot easily provide your own one
>>>>> because it might interfere with the original one.
>>>>> >
>>>>> > You could probably build and package the custom version of wxWidgets
>>>>> within a homebrew/MacPorts recipe for KiCad, but then there is really no
>>>>> advantage in using such a system to build yourself (i.e., sharing libraries
>>>>> across the system).
>>>>> > Just take Adam’s nightly builds which do the same (just without a
>>>>> recipe).
>>>>>
>>>>> I’m sure I speak for a lot of Mac users when I say:
>>>>>
>>>>> We greatly prefer a simple disk image with either an installer or a
>>>>> package with the program we can drag to /Applications and libraries to the
>>>>> usual install locations.
>>>>>
>>>>> Homebrew and the like are perhaps fine if people want to build from
>>>>> source. Having too many package managers seems to muck things up, and I
>>>>> prefer not using any of them.
>>>>>
>>>>> Just my view, of course.
>>>>>
>>>>> -a
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>