Hey Fred Jan,
That is a good process, I do it a lot, thanks for writing it up. I think the next step is getting everything compiling so that we have complete builds each night. That makes testing much easier since a) the build process is automated, and b) all of the libraries are easily available for testing.
I can run automated tests on the build machines, once we start generating them.
.hc
On Oct 22, 2011, at 3:46 PM, F.J. Kraan wrote:
Hi,
The last few days I have been toying with the pd-double-auto-builder script, and with some hacking I isolated the externals which failed to compile, resulting in few objects reaching the package. This is what I did:
modified external/Makefile:
- selectively removed targets until all resulting in make errors are
removed. For the current situation these are: creb, cw_binaural, extra, smlib, vbap, gem The package process depends on the compile result, so when there is no compile error, all build objects are packaged. With a compile error, only vanilla is packaged.
For this to work, I modified the pd-double-auto-builder.sh:
- removed the initial rsync download and the final rsync upload
The advantage is that one can modify and keep files as the rsync- download replaces all modified local files and delete all added files.
These changes resulted in a software package of 22.7 MByte containing more compiled objects.
This is of course, not a proposal to change the pd-double-auto-build scripts. But it helped finding the problematic externals.
Please note the obvious that compiling does not mean work. I did some work here too, but progress is slow. I know testing, but not much Pd.
Fred Jan
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs