[nanomsg] Re: New fork (was Re: Moving forward)
- From: Martin Lucina <martin@xxxxxxxxxx>
- To: Garrett D'Amore <garrett@xxxxxxxxxx>
- Date: Mon, 23 Mar 2015 18:13:44 +0100
garrett@xxxxxxxxxx said:
> Looking at what we have today, if we can keep the build slaves running for
> just a wee bit longer, I think it would be useful.
Based on my discussion with the owners of the space where the build slaves
I host are located, they don't seem to have any immediate plans for it and
are happy to let me leave machines running there even after my lease
officially ends.
However, I obviously can't make any guarantees about how long things will
stay that way.
> But it also sounds like you’re planning on retiring the SPARC servers you
> have?
The Solaris/SPARC build is running on a now ancient Sun Blade 100, so as
long as my previous paragraph holds and the hardware keeps working it'll
keep running.
> That said, we’re going to miss CI for a lot of other platforms — people are
> running nanomsg on ARM systems, in iOS, on OpenBSD, NetBSD, HPUX, VxWorks
> (?), etc. We can’t have CI for all of them at this point in time. The loss
> of FreeBSD would be a shame, and I have personal reasons for wishing we’d
> have CI support for Solaris or illumos (esp. the latter), but again, I don’t
> think any of the CI providers have an interest.
Have you looked at the current setup?
http://build.nanomsg.org/waterfall
We currently have the following slaves:
1) 'nanomsg-linux', autoconf, Debian Linux 7 on x86_64
2) 'nanomsg-freebsd', autoconf, FreeBSD 9 on i386
3) 'nanomsg-solaris', autoconf, Solaris 10 on SPARC
4) 'nanomsg-win32', cmake, Windows Server 2008 on i386
5) 'nanomsg-macosx', autoconf, MacOSX ? on ?
6) 'nanomsg-netbsd', autoconf, NetBSD ? on i386
Out of the above, 1) - 4) are hosted at the location that is going away. 5)
and 6) are provided by volunteers elsewhere.
Out of those slaves that are going away, 1) and 2) are fairly trivial to
migrate to my Xen setup once that's ready. 3) is obviously stuck (SPARC)
and while 4) could probably run on Xen as a HVM domain, I don't want it
on my box :-)
> Right now, its unclear to me that our current CI setup does anything more
> than verifying that stuff builds. The self tests don’t seem to be built
> unless building with cmake on Windows. That’s something that needs to be
> fixed. Frankly, I think there is more value in having the self-tests
> execute, even if *only* on Linux, then on ensuring we are still building on
> other platforms. (Not that I want to stop supporting those other platforms.)
It does build and run the tests for both CMake and autoconf based builds
(see above). Always has done.
> The other thing I’d to do is get us using appveyor for Windows testing. I’m
> most definitely *not* a Windows developer, but it seems that there is a lot
> of effort that has been expended to support that platform, and it would be
> nice if we could ensure we didn’t regress on it. That becomes especially
> important as I don’t have any systems running windows within normal easy
> reach of me.
We already have Windows and have had for some time. See above.
-mato
Other related posts:
