(I discussed this with Abe and he asked to send it to the mailing list)
I'm thinking of writing a patch that creates a build dir per configuration.
Assume that Test::Smoke is configured with:
==
-Duseithreads
==
/-DDEBUGGING/
-DDEBUGGING
Then it will build perl with:
1) -Duseithreads
2) -Duseithreads -DDEBUGGING
The current execution looks like:
- cleans the build directory; builds perl with -Duseithreads;
- cleans the build directory; builds perl with -Duseithreads -DDEBUGGING;
When the smoke is finished then the build dir contains a perl
configured with -Duseithreads -DDEBUGGING.
If a test failure is detected in the -Duseithreads -DDEBUGGING
configuration then it is "easy" to investigate it further since the
perl still exist.
If a test failure is detected in the -Duseithreads configuration then
one first has to build perl again and wait for it to finish.
What I propose is adding an option which enables the building of each
perl in a separate build directory:
1) -Duseithreads is build in /some/build-dir/1/ (or similar)
2) -Duseithreads -DDEBUGGING is build in /some/build-dir/2/ (or similar)
When the smoke is finished then it "easy" to investigate each perl
since it does not need to be rebuild (the configuration still exists).
What this also allow:
Assume: the smoke of the day before showed a test failure
A fix for it is added in blead and today the smoke is started.
Assume2: the smoke takes 13 hours to complete and you are impatient.
When you see that it is smoking the next configuration then you can
manually run the test script on the broken configuration to know the
result of the patch (that is, without needing to wait 13 hours and
without needing to build the perl manually.)
Abe said:
[15:06] <@abeltje> I'm torn between building in a separate directory
or installing in a separate directory
[15:09] <@Bram> You mean: configure with -Dprefix=.... and a make install ?
[15:09] <@abeltje> yup
[15:09] <@abeltje> has the same benefits as building in a seperate dir imo
One reason against this:
The install directory does not contain the object files or the
makefiles. So changing a .c file and running make is not possible.
Comments/thoughts?
Kind regards,
Bram
