Building and Testing a Canadian Cross-Compiler

[Gedare Bloom]

On Sun, Mar 24, 2013 at 11:40 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
> Hi,
>
> I think moving to another build system is really worth considering. Virtually every build system is faster than autotools, and hopefully we could then do continuous integration (hint, hint). One of the fastest ones from the comparison charts I showed earlier was a build system composed of just Makefiles, it even beat out Waf... Although Waf was also much faster than autotools (so maybe good enough)... perhaps we could identify what our build system priorities are, and how to accomplish them with a new build system.
>
Maintaining platform-independent Makefiles is not an attractive option
despite the performance. Waf provides platform-independence, even more
so than autotools.

> I know Fedora is the build of choice for RTEMS, what other build (not necessarily host) systems should we be looking at? I'm using Ubuntu, and started playing with pcBSD (as it's in the top 10 on distrowatch). Other distros on distrowatch I thought were worth concentrating on were: slackware (but that cost money which I don't want to spend), arch,  and Ubuntu.
>
macos, *bsd, rpm-based distros centos/rhel/suse, deb-based distros
debian/ubuntu, archlinux, gentoo, raspbian, windows

> The ones I'm not so sure how much of priority Mageia, CentOS, PCLinuxOS, and openSUSE are... because they use rpms, so after handling the Fedora build, versions are probably the main issue there.  Similarly, Debian is where Ubuntu packages originate from (but paradoxically Debian uses much older package versions in general and is even farther in the dust than Ubuntu), while Mint is an Ubuntu derivative (that lags about 6 months behind Ubuntu).
>
I have been convinced that RTEMS Project should not be in the business
of providing upstream distros with RTEMS-related packages. Yielding
"control" of the packages in that manner is not good for end users,
especially if the package maintainer decides to stop updating those
upstream packages. We can, however, provide packages for distributions
if package maintainers are available for them, e.g. how the RPMs are
dealt with currently. We need to define more policies and procedures
for how these tools are produced and maintained though.

> It may be interesting to determine if proprietary build systems are worth considering, such as Windows and Mac... do we even want to consider build systems on mobile devices? They would be slow, but I run my laptop overnight when doing gcc-testing on a VM...
>
All reasonable build platforms should be at least considered.
Proprietary build platforms are as valid and important to include in
these discussions as open platforms.

-Gedare

> Thanks,
> Cynthia Rempel
>
> ________________________________________
> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Chris Johns [chrisj at rtems.org]
> Sent: Sunday, March 24, 2013 6:38 PM
> To: rtems-devel at rtems.org
> Subject: Re: Building and Testing a Canadian Cross-Compiler
>
> Ralf Corsepius wrote:
>> Yes, definitely ... The autotool generated sources (e.g. Makefile.in,
>> config.h etc.) definitely belong into git.
>
> This topic has been discuss on the list and it was decided these should
> not be in git. Lets please not rehash an old discussion that was clearly
> resolved.
>
>> However, when having done so, the patches were immediately reverted and
>> was virtually shot down - These incidents actually are the reason for my
>> current deep dissatisfation with certain people around here.
>
> It is unfortunate autoconf and automake is causing this. Given the
> problems building these specific tools and the fact we cannot upgrade to
> the latest automake, maybe after 4.11 is released we move to RTEMS 5.0
> and a new build system that removes this as a problem.
>
> Chris
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel