dcwbrown
commented
8 years ago The first 6 paras above are now implemented, the builds compare the generated C source with the corresponding bootstrap. Needless to say given the recent change in hex literal handling and the removal of duplicate lines in SYSTEM.H they show as changed.
Supporting a dynamic build status implies checking in an update staus file from time to time until the build has completed on all machines. At this point it would make sense to mark the repository with a new version number.
I need to make the version string a variable in Configuration.Mod. Currently it's a constant, which means it gets compiled into each module that uses it and so 2 compiler modules always appear different (and so are currently omitted from the checksum test.)
Need a way for the build to indicate a checksum change is expected, e.g when the compiler hexliiteral parsing was corrected.
Actually, storing the checksum is turning out to be unhelpful - when the report shows a checksum change there is no information around to help analyse why it changed. Really I need to compare the previous and new .c and.h files to see what has changed.
But in fact the .c and .h files should match the bootstrap sources except in a very few details (especially the version info comment at the start.)
So I'll drop the checksum support and replace it with a diff between the newly built .c and .h sources and the corresponding bootstrap source (bypassing the version comment).
Is it sufficient to do this for the compiler modules, or is it necessary for the library too? I'll stick with the compiler for now.
The build status needs to reflect the current branch and SHA. When the build completes the status report should get checked into the repository - so when looking at earlier versions of the repository the status matches that version. (Currently there is just one status reflecting the latest build whichever branch it was on.)
And it would be nice if the status updated dynamically up to the point that the builds complete.
Obviously when the completed status report gets checked in, the github webhook will need to recognise that it's only a status change and not trigger another automatic build.
For the Windows builds I am going to need to run all 6 builds in sequence and the machine is not very fast. (The builds are: cygwin32 cygwin64 mingw32 mingw64 msc32 msc64.)
Generation of the bootstrap sources must currently be done from a 64 bit environment, there is an issue with the source generated on a 32 bit machine being able to generate source for a 64 bit machine. With the source checking above it may be necessary to generate the 32 bit bootstraps from a 32 bit environment. That's a bit of a nuisance. I can most easily do this from cygwin as I can build both 32 and64 bit enlistments on the same machine with cygwin. In the long term I think it will be possible to generate both 32 bit and 64 bit compilers from any compiler, making this easier. See roadmap for some related thoughts.