On 11/03/2013 12:16 PM, Philip Nienhuis wrote:
Rik wrote:
On 11/03/2013 10:00 AM, address@hidden wrote:
Forgot to mention:
I cross-build them by first building Octave on/for Linux and running "make
check", then do "make all dist" and transplant that<dist>.tar.gz to
mxe-octave for building.
How much does "make distcheck" differ from "make all dist"?
The 'distcheck' target is a GNU standard target which performs all of the
operations associated with packaging a distribution and verifying that the
distribution works. If it passes 'distcheck', it is very likely to work
for users.
Specifically it:
1) Runs 'make all' to verify that the code can be built
2) Runs 'make dist' to verify that a tarball can be created
3) Creates a temporary directory and unpacks the tarball into a source/
directory
4) Creates a temporary build directory
5) Runs 'configure' and 'make' to do an out-of-source tree build
6) Runs 'make check' to verify that tests pass
7) Runs 'make dist' to test that the tarball is sufficient to create
another tarball, as might happen if a distribution patches a few files.
8) Runs 'make distclean' to verify that no temporary files are created
which leave lingering state information and could cause subsequent builds
to fail.
Thanks very much for this explanation. How I wish more OSS projects
adopted such a procedure...
Projecting those steps on what I do:
- Steps 1& 2 are done when building the Octave tip in Linux.
- Steps 3, 4& 5 are done in the mxe-octave build process.
- An intermediate step 5.5 comprises transferring to& installing the
Octave installer in Windows.
- Step 6 is replaced by running __run_test_suite__ in the just installed
Octave in Windows.
...and that's about it.
(You probably guess what I'm writing down here:)
I'm wondering what the point of "make distcheck" in mxe-octave is; after
all, the final test for both Windows and Mac OSX would rather be whether
the compiled binary works. At least, that's my more down-to-earth (rude
if you want) perception of "it is very likely to work for users".
I think that's right. For cross-compiled binaries the true test is whether
they run on the target platform. 'make distcheck' catches the ordinary
situation, for UNIX anyways, where you want to download a tarball and then
run "configure; make; make install" and have it work.
The way you describe it looks primarily like a developer target. Now that
you've explained it I fully understand the point of that; I regularly
encounter SW that doesn't work because some stupid dependency is lacking
(e.g., odfdom 0.8.9). But for platforms like OSX and Windows I expect
very few users are going to build their own Octave.
Yes, the convention on these systems is towards pre-compiled binaries
rather than source code distributions. Partly, of course, because
Microsoft never shipped a C compiler by default and you had to pay for it
if you wanted it.
I think "make distcheck" could in principle be executed on MinGW (i.e,
natively), possibly with mxe-octave built dependencies.
But alas! mxe-octave natively (= on Windows) still doesn't work. I've
been mailing privately with John Donoghue this weekend about the various
hickups I encounter with it. AFAIU it doesn't work for him either using
one simple "./mk-dist" command. Some dependencies and maybe octave
itself still have to built using a "manual" 'make' intervention.
(But I'd like to stress that cross-compiling using mxe-octave works like
a charm - for me)
So I think you're procedure seems like a good one. There is one difference
that is possibly noteworthy. I usually run 'make check' from the shell
prompt rather than '__run_test_suite__' from within Octave. It doesn't
seem like a big deal, but I get more test failures from __run_test_suite__
than I do from the other. Specifically, there is only 1 failure with 'make
check', but 8 with __run_test_suite__. Also, the number of tests is
different (11522 passing versus 11471 passing). I can replicate 'make
check' from within Octave by doing 'cd test; fntests' to switch to the test
directory and run the test script there. This seems to be because
__run_test_suite__ is looking for where the tests will have been installed
(such as /usr/local/...) rather than where the tests are (the current build
directory which is what fntests does).