On Wed, 24 Dec 2014 09:55:37 +0000, Vincent Sanders wrote:
> as we discovered with beos, gcc 2.95 support is a bit hit and
> miss. Though I beleive the main issue there was g++, even so I fear
> 2.95 is too primative and is almost 14 years old at this point.
I agree we shouldn't go back to such an old version.
> > There are loads of patches here:
> > https://github.com/cahirwpz/m68k-amigaos-toolchain
> >
> > There are an excessive number and I have no idea which are relevant.
>
> That is terrifying, I really do think that if they want continuing
> compiler support they need to look at a modern gcc version or a clang
> port.
And getting the patches merged back upstream would be a good idea too.
It looks like that must never have happened for m68k-amigaos.
> Alas wishing does not make it so, being pragmatic, if there is a
> "cannonical" cross toolchain for the target I might be persuaded to
> put it on the CI as long as we can "package" it under /opt/netsurf
> correctly so builds are repeatbale. I dislike this a lot but if it is
> the only way...
I'd rather get the official 3.4.6 source and import the patches we
need from that repo (even if that's all of them under
patches/gcc-3.4.6). I did try building it with our current patches
but it clearly needs more as I get errors with register defines
(REG_A0 etc), unless I'm doing something wrong.
Chris
Wednesday, 24 December 2014
Core buildsystem changes
The recent developer weekend gave John-Mark and myself opportunity to
improve the core buildsystem (used for all the libraries) to use
standard "triplet" type identifiers for the ABI being compiled. This
means we now query the compiler [1] about the binary it will build to
setup cross compiling.
We use the environment values for HOST, HOST_CC, BUILD and CC in a
similar manner to how the gnu tooling uses them. Simply:
BUILD - The compiler triplet of the system running the compiler, this
can almost always be omitted and will be detected automatically.
CC - The build systems compiler, allows overriding of the default
compiler (cc) searched for on the PATH
HOST - This is the compiler triplet of the system we are building for,
it it differs from BUILD then we are performing a cross compile.
The compiler name is constructed using this unless HOST_CC is
specified.
HOST_CC - override the constructed compiler name for cross
compilation, the path and details for all the tools are
derived from this.
The core buildsystem has been updated along with the environment
script [2] so in general this has a low impact on developers but a
great gain for more complex build setups such as the CI system.
[1] This uses "cc -dumpmachine"
[2] http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh
--
Regards Vincent
http://www.kyllikki.org/
improve the core buildsystem (used for all the libraries) to use
standard "triplet" type identifiers for the ABI being compiled. This
means we now query the compiler [1] about the binary it will build to
setup cross compiling.
We use the environment values for HOST, HOST_CC, BUILD and CC in a
similar manner to how the gnu tooling uses them. Simply:
BUILD - The compiler triplet of the system running the compiler, this
can almost always be omitted and will be detected automatically.
CC - The build systems compiler, allows overriding of the default
compiler (cc) searched for on the PATH
HOST - This is the compiler triplet of the system we are building for,
it it differs from BUILD then we are performing a cross compile.
The compiler name is constructed using this unless HOST_CC is
specified.
HOST_CC - override the constructed compiler name for cross
compilation, the path and details for all the tools are
derived from this.
The core buildsystem has been updated along with the environment
script [2] so in general this has a low impact on developers but a
great gain for more complex build setups such as the CI system.
[1] This uses "cc -dumpmachine"
[2] http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh
--
Regards Vincent
http://www.kyllikki.org/
RSS feed and Sargasso
I use Sargasso to show the RISC OS Open posts feed.
Noticing an RSS link on:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
which, as I have noted earlier no longer gives much/any useful information,
I tried the link:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/rssAll
in Sargasso, but it doesn't work.
Can anyone advise on a correct URL, ie, one that /will/ work?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
Noticing an RSS link on:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/changes
which, as I have noted earlier no longer gives much/any useful information,
I tried the link:
http://ci.netsurf-browser.org/jenkins/view/All/job/netsurf/rssAll
in Sargasso, but it doesn't work.
Can anyone advise on a correct URL, ie, one that /will/ work?
John
--
| John Williams
| johnrw@ukgateway.net
Names for Soul Band:- Soul Trader(s) *
CI updates
I have recently had the opportunity to greatly improve the NetSurf CI
build infrastructure both in terms of hardware and software.
On the hardware side I would like to thank Mythic Beasts [1] for once
again generously donating a 1u rack server. This is a 8 core Xeon with
24G of memory which replaces their previous donation of a 4 core 8G
system.
This server is the projects primary VM host for CI build slaves and
the bug tracker. It continues to be hosted by Collabora [2] in
Cambridge. Other services the project uses, like the website,
remain hosted by Pepperfish [3] for which I would also like to extend
my appreciation.
The new hardware has reduced the NetSurf CI rebuild time under
150seconds (down from 300) on all ten currently built operating
systems and allowed the addition of more build combinations improving
the utility to the developers.
The additional memory has allowed us to add more build slaves and
hence extend the number of OS built for. Also the number of checks
performed in analysis jobs[4] was extended.
The CI software has been upgraded to the latest version of jenkins
along with all the other plugins.
I used the opportunity to complete the improvements to the development
build process which was started at the developer weekend. This has
resulted in the job history and rss feed data for many CI jobs
(including the main NetSurf job) being reset, apologies if this
adversely affects anyone but as new builds are performed the history
backlog will build up again.
As a note builds are only performed if commits to the git
repository[5] occur, we do not perform periodic (daily) builds in
general. As there have not been many commits recently there have been
very few builds, this is correct and expected behaviour.
[1] https://www.mythic-beasts.com/
[2] https://www.collabora.com/
[3] http://www.pepperfish.net/
[4] http://ci.netsurf-browser.org/jenkins/job/scan-build-netsurf/
[5] http://git.netsurf-browser.org/
--
Regards Vincent
http://www.kyllikki.org/
build infrastructure both in terms of hardware and software.
On the hardware side I would like to thank Mythic Beasts [1] for once
again generously donating a 1u rack server. This is a 8 core Xeon with
24G of memory which replaces their previous donation of a 4 core 8G
system.
This server is the projects primary VM host for CI build slaves and
the bug tracker. It continues to be hosted by Collabora [2] in
Cambridge. Other services the project uses, like the website,
remain hosted by Pepperfish [3] for which I would also like to extend
my appreciation.
The new hardware has reduced the NetSurf CI rebuild time under
150seconds (down from 300) on all ten currently built operating
systems and allowed the addition of more build combinations improving
the utility to the developers.
The additional memory has allowed us to add more build slaves and
hence extend the number of OS built for. Also the number of checks
performed in analysis jobs[4] was extended.
The CI software has been upgraded to the latest version of jenkins
along with all the other plugins.
I used the opportunity to complete the improvements to the development
build process which was started at the developer weekend. This has
resulted in the job history and rss feed data for many CI jobs
(including the main NetSurf job) being reset, apologies if this
adversely affects anyone but as new builds are performed the history
backlog will build up again.
As a note builds are only performed if commits to the git
repository[5] occur, we do not perform periodic (daily) builds in
general. As there have not been many commits recently there have been
very few builds, this is correct and expected behaviour.
[1] https://www.mythic-beasts.com/
[2] https://www.collabora.com/
[3] http://www.pepperfish.net/
[4] http://ci.netsurf-browser.org/jenkins/job/scan-build-netsurf/
[5] http://git.netsurf-browser.org/
--
Regards Vincent
http://www.kyllikki.org/
Re: m68k amigaos toolchain
On Sat, Dec 20, 2014 at 09:47:14PM +0000, Chris Young wrote:
> On 20 Dec 2014 20:52:25 +0000, Chris Young wrote:
>
> > Furthermore, there's something broken in the compiler as
> > everything it builds causes a system freeze on exit.
>
> I suspect this is down to the version of gcc being used. Everybody
> seems to be stuck on 2.95 still, and the only other version I've seen
> in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
> generate as good 68k code compared to 2.95)
as we discovered with beos, gcc 2.95 support is a bit hit and
miss. Though I beleive the main issue there was g++, even so I fear
2.95 is too primative and is almost 14 years old at this point.
>
> There are loads of patches here:
> https://github.com/cahirwpz/m68k-amigaos-toolchain
>
> There are an excessive number and I have no idea which are relevant.
That is terrifying, I really do think that if they want continuing
compiler support they need to look at a modern gcc version or a clang
port.
Alas wishing does not make it so, being pragmatic, if there is a
"cannonical" cross toolchain for the target I might be persuaded to
put it on the CI as long as we can "package" it under /opt/netsurf
correctly so builds are repeatbale. I dislike this a lot but if it is
the only way...
>
> I've pushed the patches to make libcurl build as a pure clib2 library,
> so the SDK at least completes.
Excellent, thanks for that. I pushed the rebuild on the CI so we
should be able to get a build through in an hour or so. I also enabled
the target for most of the libraries, as expected the netsurf build
itself does not yet work but when you are ready let me know whats
needed and I will turn it on.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
> On 20 Dec 2014 20:52:25 +0000, Chris Young wrote:
>
> > Furthermore, there's something broken in the compiler as
> > everything it builds causes a system freeze on exit.
>
> I suspect this is down to the version of gcc being used. Everybody
> seems to be stuck on 2.95 still, and the only other version I've seen
> in use for m68k-amigaos is 3.4 (along with notes saying it doesn't
> generate as good 68k code compared to 2.95)
as we discovered with beos, gcc 2.95 support is a bit hit and
miss. Though I beleive the main issue there was g++, even so I fear
2.95 is too primative and is almost 14 years old at this point.
>
> There are loads of patches here:
> https://github.com/cahirwpz/m68k-amigaos-toolchain
>
> There are an excessive number and I have no idea which are relevant.
That is terrifying, I really do think that if they want continuing
compiler support they need to look at a modern gcc version or a clang
port.
Alas wishing does not make it so, being pragmatic, if there is a
"cannonical" cross toolchain for the target I might be persuaded to
put it on the CI as long as we can "package" it under /opt/netsurf
correctly so builds are repeatbale. I dislike this a lot but if it is
the only way...
>
> I've pushed the patches to make libcurl build as a pure clib2 library,
> so the SDK at least completes.
Excellent, thanks for that. I pushed the rebuild on the CI so we
should be able to get a build through in an hour or so. I also enabled
the target for most of the libraries, as expected the netsurf build
itself does not yet work but when you are ready let me know whats
needed and I will turn it on.
>
> Chris
>
>
--
Regards Vincent
http://www.kyllikki.org/
Tuesday, 23 December 2014
Re: Daily builds
On Tue, Dec 23, 2014 at 13:22:32 +0000, Peter Slegg wrote:
> Have the daily builds been running since the 21st ?
We do not run 'daily builds' -- we run builds whenever a developer adds code to
the project. Given it is the Christmas period, most of the developers are a
tad busy.
I'd guess you might see new builds after Boxing day when we all start to get a
little fed up with 'family' :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
> Have the daily builds been running since the 21st ?
We do not run 'daily builds' -- we run builds whenever a developer adds code to
the project. Given it is the Christmas period, most of the developers are a
tad busy.
I'd guess you might see new builds after Boxing day when we all start to get a
little fed up with 'family' :-)
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
Subscribe to:
Posts (Atom)