Nightly builds failed/don't work

siggi · Post by **siggi** » Tue Oct 22, 2013 7:10 pm

During the last days the nightly builds seem to have failed.

I just downloaded the latest WIN32 build, but the directory z88dk in the ZIP file has a date stamp of 2013-09-16
I tried to compile my Zeddyfox for ZX81 using the current version. I didn't get an error message, but no code nor a P file was generated :-(

Siggi

Post by **dom** » Tue Oct 29, 2013 8:20 pm

It's been broken for a while, I need to ask Paulo to check-in the code that's generated by the perl scripts - none of the machines I've set up for the build farm have an up-to-date enough perl to load one of the modules.

Post by **stefano** » Thu Oct 31, 2013 7:45 am

Fantastic, Is there a Whole build farm ?

pscust · Post by **pscust** » Thu Oct 31, 2013 5:03 pm

I have just noticed the problem my build scripts are causing. Sorry for not paying attention.

I will correct the z80asm makefile to not try to generate the files and use the committed ones if the Perl tools fail.

Regards.
Paulo

Timmy · Post by **Timmy** » Sat Nov 02, 2013 12:03 pm

In the meantime you can try to use the stable builds.

pscust · Post by **pscust** » Sun Nov 03, 2013 12:23 pm

Nightly builds working again.

Issues solved and committed to CVS:

1) Preprocessors (perl, ragel) might not be available in the target platform.
Ignore errors when calling these tools and use the pre-generated files
that are in the CVS repository.

2) Fix error: redefinition of typedef in init.h - this error is ignored by the Win32 compilers I am using (VS2010, MinGW)

3) g_slist_free_full() requires GLib 2.28, replaced by g_slist_foreach() and g_slist_free()

Regards,
Paulo

Post by **dom** » Tue Nov 05, 2013 11:33 am

Thanks very much Paulo.

Re build farm, not really...just a single VM running on my home server. I do way too much build stuff at work so the phrase just slipped out

I'm planning on adding an OS X build as well if I can build a working cross compiler, or get 10.8 running under virtualisation. So maybe that point I'll be able to get away with saying it!

Post by **stefano** » Tue Nov 05, 2013 7:13 pm

Ok, I try not to do your same error and start talking of international L2 balancers

Post by **dom** » Tue Nov 05, 2013 9:24 pm

Now they are the bain of one of the other parts of my job....that and badly configured F5s.

I hope you've got nothing to do with that environment in Munich....

Post by **stefano** » Tue Nov 05, 2013 9:42 pm

Let's say I'm trying to act as the customer regarding the f5.. I'm not sure the trick will work tough !

Post by **stefano** » Thu Nov 07, 2013 10:52 am

Sorry for keeping this thread open, but after three times it looks that the nightly batches are not running anymore.. ??

siggi · Post by **siggi** » Tue Mar 04, 2014 1:01 pm

stefano wrote:Sorry for keeping this thread open, but after three times it looks that the nightly batches are not running anymore.. ??

Indeed

Siggi

Post by **alvin** » Tue Mar 04, 2014 3:02 pm

Paulo is working on the expression evaluator in z80asm. I think the current commit no longer recognizes hex constants specified by a terminating "H" or "h", which is present in some old code. I posted a message in the developer list so he can have a look.

Post by **dom** » Tue Mar 04, 2014 6:33 pm

Thanks Alvin, I'm out of the country at the moment (actually in yours I think) so I'd not been able to chase the cause of them.

The build before nightly broke should have the pragma scanner for sdcc enabled though so might be worth a spin.

pscust · Post by **pscust** » Thu Mar 06, 2014 10:44 pm

I have fixed the problem.

Explanation:

The original z80asm scanner used a simple heuristic to convert an identifier to a number if it was only composed of hex digits and an 'H' at the end.

This caused unexpected syntax errors with identifiers with only hex digits, e.g.

EACH: NOP

stopped with a syntax error, as EACH was interpreted as the constant 0x0EAC.

I have changed the scanner to the common processing of hex constants in assemblers: a hex constants ending with an 'H' needs to start with a digit, or be prefixed with a zero.

This change caused the nightly-build to start failing.

As there were only about 20 such hex constants in the z88dk library, I have now added the zero prefix to the constants to solve the problem. The line above became:

ld ix,0ACECH

Regards,
Paulo

siggi · Post by **siggi** » Fri Apr 11, 2014 8:28 am

siggi wrote:
stefano wrote:Sorry for keeping this thread open, but after three times it looks that the nightly batches are not running anymore.. ??
Indeed

Siggi

Once more ...

Post by **stefano** » Fri Apr 11, 2014 2:35 pm

z80asm is being heavily reworked.. let's give Paulo time to think or let's only help him spotting the problem.

(Same for the libraries)

Timmy · Post by **Timmy** » Thu Jul 30, 2015 1:48 pm

I thought I'm bumping this as there's been no builds for 2 weeks now.

Post by **alvin** » Thu Jul 30, 2015 2:02 pm

Timmy wrote:I thought I'm bumping this as there's been no builds for 2 weeks now.

Sourceforge had a storage fault on July 17 affecting all sf projects. Only in the past few days have services begun to come online. z88dk's sf repository won't likely be available until August 3. The builds are failing because the build machine cannot access the repository at sf and won't be able to until around August 3. Until then the last successful update is all that is available.

Timmy · Post by **Timmy** » Thu Jul 30, 2015 3:05 pm

Thanks for the info, I forgot about z88dk being stored in SF.

By the way, do you have plans to move your repository to github, like every active SF project is doing, or already did?

Post by **dom** » Thu Jul 30, 2015 9:52 pm

The only thing we use sf for these days is the source code repo so migration away should be pretty simple.

Moving to a git hosting is an obvious choice - when I'm recovered I'd like to look at a repo conversion tool that preserves history in a nice way.

Post by **alvin** » Fri Jul 31, 2015 12:39 am

dom wrote:Moving to a git hosting is an obvious choice - when I'm recovered I'd like to look at a repo conversion tool that preserves history in a nice way.

If we're considering this maybe we should do a source code reorganization at the same time.