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
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
On 2011-10-22 22:12, Hans-Christoph Steiner wrote:
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.
I was thinking about creating a simple array compare patch, as you already proposed, which can be used to compare signal output from an object-under-test with a reference array. Using that as template it is relative simple to create lots of regression tests.
It is beyond my pd-knowledge to create such a template, but the local pd-guru promised me it is doable. I'll let you know if we have something usable.
Fred Jan
On Oct 22, 2011, at 5:11 PM, F.J. Kraan wrote:
On 2011-10-22 22:12, Hans-Christoph Steiner wrote:
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.
I was thinking about creating a simple array compare patch, as you already proposed, which can be used to compare signal output from an object-under-test with a reference array. Using that as template it is relative simple to create lots of regression tests.
It is beyond my pd-knowledge to create such a template, but the local pd-guru promised me it is doable. I'll let you know if we have something usable.
Fred Jan
Looking forward to this, don't hesitate to ask any questions here. I think that this kind of testing is quite important, so I'd like to help where I can.
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
-
F.J. Kraan -
Hans-Christoph Steiner