CI integration for Octave on OSX

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

CI integration for Octave on OSX

c.-2
Hi all,

Brad from the macports project offered to help us set up a
Continuous Integration (CI) OS X system online for Octave.

To get this started it would help to have the details of
the "build.x86_64-darwin" builder on Hydra:

http://hydra.nixos.org/jobset/gnu/octave-default#tabs-jobs

I am not an expert with the Hydra system can someone help with this?

Thanks,
c.

Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Mike Miller
On Wed, Dec 03, 2014 at 10:45:35 +0100, c. wrote:

> Hi all,
>
> Brad from the macports project offered to help us set up a
> Continuous Integration (CI) OS X system online for Octave.
>
> To get this started it would help to have the details of
> the "build.x86_64-darwin" builder on Hydra:
>
> http://hydra.nixos.org/jobset/gnu/octave-default#tabs-jobs
>
> I am not an expert with the Hydra system can someone help with this?

Yes, absolutely. I think I'm the closest thing to an expert that we have
here :/

To start, the Octave part of the Hydra build job is here:

  http://git.savannah.gnu.org/cgit/hydra-recipes.git/tree/octave/release.nix

This file describes what other builds Octave depends on, and what
options and environment are needed to run bootstrap, configure, make,
etc.

Btw, there seems to be a "x86_64-darwin" target available in Hydra, I am
honestly not sure what it consists of, but several of the GNU builds are
using it, e.g.

  http://hydra.nixos.org/jobset/gnu/emacs-trunk#tabs-jobs

I could try adding that target to our build file and just see what
happens...

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Jordi Gutiérrez Hermoso-2
On Wed, 2014-12-03 at 08:46 -0500, Mike Miller wrote:
> Btw, there seems to be a "x86_64-darwin" target available in Hydra,
> I am honestly not sure what it consists of, but several of the GNU
> builds are using it, e.g.

I asked the GNU folks. This target would build Octave on Mac OS X
(it's not really Darwin, that OS doesn't exist anymore). I'm not sure
how useful it would be, because the resulting binary depends on the
entirety of the Nix system. I also don't know what compiler it's
building with, so if we see build failures, it might not be that
useful. It's probably some version of Xcode.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Mike Miller
On Wed, Dec 3, 2014 at 09:28:53 -0500, Jordi Gutiérrez Hermoso wrote:
> I asked the GNU folks. This target would build Octave on Mac OS X
> (it's not really Darwin, that OS doesn't exist anymore). I'm not sure
> how useful it would be, because the resulting binary depends on the
> entirety of the Nix system. I also don't know what compiler it's
> building with, so if we see build failures, it might not be that
> useful. It's probably some version of Xcode.

Ok, thanks for looking into that. It might be useful just as one more
automated build test case, but ultimately probably not what we really
want for builds on OS X, since it would depend on the rest of the Nix
package system, which sounds like yet another different environment
from stock OS X or macports or homebrew or ...

Brad, Carlo, is the main intent to produce build logs and bug reports,
or to produce an end-user-installable app/dmg/whatever? It would be
good to define up front what the goal of this CI system will be.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Bradley Giesbrecht

On Dec 3, 2014, at 8:50 AM, Mike Miller <[hidden email]> wrote:

> On Wed, Dec 3, 2014 at 09:28:53 -0500, Jordi Gutiérrez Hermoso wrote:
>> I asked the GNU folks. This target would build Octave on Mac OS X
>> (it's not really Darwin, that OS doesn't exist anymore). I'm not sure
>> how useful it would be, because the resulting binary depends on the
>> entirety of the Nix system. I also don't know what compiler it's
>> building with, so if we see build failures, it might not be that
>> useful. It's probably some version of Xcode.
>
> Ok, thanks for looking into that. It might be useful just as one more
> automated build test case, but ultimately probably not what we really
> want for builds on OS X, since it would depend on the rest of the Nix
> package system, which sounds like yet another different environment
> from stock OS X or macports or homebrew or ...
>
> Brad, Carlo, is the main intent to produce build logs and bug reports,
> or to produce an end-user-installable app/dmg/whatever? It would be
> good to define up front what the goal of this CI system will be.
I understand the goal to be "end-user-installable app/dmg/whatever".

It may be necessary to have multiple "apps" for different versions of OS X, is there a policy in place for backward compatibility?

--
Brad

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Bradley Giesbrecht
On Dec 3, 2014, at 11:48 AM, Ben Abbott <[hidden email]> wrote:

>> On Dec 3, 2014, at 1:11 PM, Bradley Giesbrecht <[hidden email]> wrote:
>>
>> On Dec 3, 2014, at 8:50 AM, Mike Miller <[hidden email]> wrote:
>>
>>> On Wed, Dec 3, 2014 at 09:28:53 -0500, Jordi Gutiérrez Hermoso wrote:
>>>> I asked the GNU folks. This target would build Octave on Mac OS X
>>>> (it's not really Darwin, that OS doesn't exist anymore). I'm not sure
>>>> how useful it would be, because the resulting binary depends on the
>>>> entirety of the Nix system. I also don't know what compiler it's
>>>> building with, so if we see build failures, it might not be that
>>>> useful. It's probably some version of Xcode.
>>>
>>> Ok, thanks for looking into that. It might be useful just as one more
>>> automated build test case, but ultimately probably not what we really
>>> want for builds on OS X, since it would depend on the rest of the Nix
>>> package system, which sounds like yet another different environment
>>> from stock OS X or macports or homebrew or ...
>>>
>>> Brad, Carlo, is the main intent to produce build logs and bug reports,
>>> or to produce an end-user-installable app/dmg/whatever? It would be
>>> good to define up front what the goal of this CI system will be.
>>
>> I understand the goal to be "end-user-installable app/dmg/whatever".
>>
>> It may be necessary to have multiple "apps" for different versions of OS X, is there a policy in place for backward compatibility?
>
> Are you asking about OS compatibility? Meaning "Should a bundle created on Mavericks run on Yosemite?"
>
> I think that would be preferred. The bundle I created on Lion still runs for me on Yosemite.
Yes, that is what I mean. As Apple and others have moved to clang/libc++ there were some "migration pains". As I understand it Lion and Mountain Lion had a mixture of gcc/clang/libstdc++/libc++ and are somewhat harder to support. Snow Leopard (last to contain rosetta/carbon/ppc compatibility) is probably easy to support as well as Mavericks forward. I'm no expert on these issues but I have read many hundreds of emails over the years discussing the issues presented by the move from gcc/libstdc++ to clang/libc++.

My main reason for asking is my intention to setup some vm's to allow us to collaborate on a solution. I have a base image for Mavericks I have been using for some KDE and MariaDB projects so I'll just start with that.

--
Brad


signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

bpabbott
Administrator
> On Dec 3, 2014, at 10:18 PM, Bradley Giesbrecht <[hidden email]> wrote:
>
> On Dec 3, 2014, at 11:48 AM, Ben Abbott <[hidden email]> wrote:
>
>>> On Dec 3, 2014, at 1:11 PM, Bradley Giesbrecht <[hidden email]> wrote:
>>>
>>> On Dec 3, 2014, at 8:50 AM, Mike Miller <[hidden email]> wrote:
>>>
>>>> On Wed, Dec 3, 2014 at 09:28:53 -0500, Jordi Gutiérrez Hermoso wrote:
>>>>> I asked the GNU folks. This target would build Octave on Mac OS X
>>>>> (it's not really Darwin, that OS doesn't exist anymore). I'm not sure
>>>>> how useful it would be, because the resulting binary depends on the
>>>>> entirety of the Nix system. I also don't know what compiler it's
>>>>> building with, so if we see build failures, it might not be that
>>>>> useful. It's probably some version of Xcode.
>>>>
>>>> Ok, thanks for looking into that. It might be useful just as one more
>>>> automated build test case, but ultimately probably not what we really
>>>> want for builds on OS X, since it would depend on the rest of the Nix
>>>> package system, which sounds like yet another different environment
>>>> from stock OS X or macports or homebrew or ...
>>>>
>>>> Brad, Carlo, is the main intent to produce build logs and bug reports,
>>>> or to produce an end-user-installable app/dmg/whatever? It would be
>>>> good to define up front what the goal of this CI system will be.
>>>
>>> I understand the goal to be "end-user-installable app/dmg/whatever".
>>>
>>> It may be necessary to have multiple "apps" for different versions of OS X, is there a policy in place for backward compatibility?
>>
>> Are you asking about OS compatibility? Meaning "Should a bundle created on Mavericks run on Yosemite?"
>>
>> I think that would be preferred. The bundle I created on Lion still runs for me on Yosemite.
>
> Yes, that is what I mean. As Apple and others have moved to clang/libc++ there were some "migration pains". As I understand it Lion and Mountain Lion had a mixture of gcc/clang/libstdc++/libc++ and are somewhat harder to support. Snow Leopard (last to contain rosetta/carbon/ppc compatibility) is probably easy to support as well as Mavericks forward. I'm no expert on these issues but I have read many hundreds of emails over the years discussing the issues presented by the move from gcc/libstdc++ to clang/libc++.
>
> My main reason for asking is my intention to setup some vm's to allow us to collaborate on a solution. I have a base image for Mavericks I have been using for some KDE and MariaDB projects so I'll just start with that.

I think it is ok to require Mac OS >= 10.9. Can Octave and the dependencies be built to support all x86_64 hardware (Core2Duo, i5, i7, etc)?

Ben
Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

c.-2

On 4 Dec 2014, at 15:12, Ben Abbott <[hidden email]> wrote:

> I think it is ok to require Mac OS >= 10.9.

If we require Mac OS >= 10.9 we can as well require Mac OS >= 10.10
and save ourselves some headaches.

I think the only bacward compatibility that would make sense is with Snow Leopard
There are users that are stuck with this version because it was the last version
with rosetta and carbon that also ran on PPC.

Other than that I think it is OK to expect a vast majority of Mac users to keep
up with the latest free OS X updates as Apple is pushing quite hard towrds this.

So, IMO, if it is easy to support multiple versions of OSX that is OK, otherwise
if it saves us some effort we could just stick with the latest version.

> Can Octave and the dependencies be built to support all x86_64 hardware (Core2Duo, i5, i7, etc)?
>
> Ben

c.
Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Bradley Giesbrecht
In reply to this post by bpabbott

On Dec 4, 2014, at 6:12 AM, Ben Abbott <[hidden email]> wrote:

>> On Dec 3, 2014, at 10:18 PM, Bradley Giesbrecht <[hidden email]> wrote:
>>
>> On Dec 3, 2014, at 11:48 AM, Ben Abbott <[hidden email]> wrote:
>>
>>>> On Dec 3, 2014, at 1:11 PM, Bradley Giesbrecht <[hidden email]> wrote:
>>>>
>>>> On Dec 3, 2014, at 8:50 AM, Mike Miller <[hidden email]> wrote:
>>>>
>>>>> On Wed, Dec 3, 2014 at 09:28:53 -0500, Jordi Gutiérrez Hermoso wrote:
>>>>>> I asked the GNU folks. This target would build Octave on Mac OS X
>>>>>> (it's not really Darwin, that OS doesn't exist anymore). I'm not sure
>>>>>> how useful it would be, because the resulting binary depends on the
>>>>>> entirety of the Nix system. I also don't know what compiler it's
>>>>>> building with, so if we see build failures, it might not be that
>>>>>> useful. It's probably some version of Xcode.
>>>>>
>>>>> Ok, thanks for looking into that. It might be useful just as one more
>>>>> automated build test case, but ultimately probably not what we really
>>>>> want for builds on OS X, since it would depend on the rest of the Nix
>>>>> package system, which sounds like yet another different environment
>>>>> from stock OS X or macports or homebrew or ...
>>>>>
>>>>> Brad, Carlo, is the main intent to produce build logs and bug reports,
>>>>> or to produce an end-user-installable app/dmg/whatever? It would be
>>>>> good to define up front what the goal of this CI system will be.
>>>>
>>>> I understand the goal to be "end-user-installable app/dmg/whatever".
>>>>
>>>> It may be necessary to have multiple "apps" for different versions of OS X, is there a policy in place for backward compatibility?
>>>
>>> Are you asking about OS compatibility? Meaning "Should a bundle created on Mavericks run on Yosemite?"
>>>
>>> I think that would be preferred. The bundle I created on Lion still runs for me on Yosemite.
>>
>> Yes, that is what I mean. As Apple and others have moved to clang/libc++ there were some "migration pains". As I understand it Lion and Mountain Lion had a mixture of gcc/clang/libstdc++/libc++ and are somewhat harder to support. Snow Leopard (last to contain rosetta/carbon/ppc compatibility) is probably easy to support as well as Mavericks forward. I'm no expert on these issues but I have read many hundreds of emails over the years discussing the issues presented by the move from gcc/libstdc++ to clang/libc++.
>>
>> My main reason for asking is my intention to setup some vm's to allow us to collaborate on a solution. I have a base image for Mavericks I have been using for some KDE and MariaDB projects so I'll just start with that.
>
> I think it is ok to require Mac OS >= 10.9. Can Octave and the dependencies be built to support all x86_64 hardware (Core2Duo, i5, i7, etc)?
Yes.

--
Brad

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CI integration for Octave on OSX

Bradley Giesbrecht
In reply to this post by c.-2
On Dec 4, 2014, at 8:06 AM, Ben Abbott <[hidden email]> wrote:

>> On Dec 4, 2014, at 10:41 AM, c. <[hidden email]> wrote:
>>
>> On 4 Dec 2014, at 15:12, Ben Abbott <[hidden email]> wrote:
>>
>>> I think it is ok to require Mac OS >= 10.9.
>>
>> If we require Mac OS >= 10.9 we can as well require Mac OS >= 10.10
>> and save ourselves some headaches.
>>
>> I think the only bacward compatibility that would make sense is with Snow Leopard
>> There are users that are stuck with this version because it was the last version
>> with rosetta and carbon that also ran on PPC.
Snow Leopard (10.6) will probably be around for a while so if Octave has SL users I would at least take a stab at supporting them, until the build systems became to dissimilar to make it not worth the extra work.

>> Other than that I think it is OK to expect a vast majority of Mac users to keep
>> up with the latest free OS X updates as Apple is pushing quite hard towrds this.
>>
>> So, IMO, if it is easy to support multiple versions of OSX that is OK, otherwise
>> if it saves us some effort we could just stick with the latest version.
>
> I think it all depends upon the difficulty. For example, Octave is easier to build on 10.9 and the 10.9 version runs on 10.10.
>
> Running Yosemite, I'm able to build Octave 3.8.2 with no problems using Fink, but have not managed that on Macports. I'm not able to build the gui-release or default branch on Yosemite at all. However, I'm able to build both on Mavericks. Until the difficulties with Yosemite are overcome, I recommend that Mavericks be the target for the app bundle.

I would be surprised if Octave built on Mavericks would not run for at least several versions to come.

I would suggest Mavericks for now, mostly because I already have vm images so why make more work at this stage :)

--
Brad

signature.asc (465 bytes) Download Attachment