Re: 'make distcheck' for MXE

[Rik]

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).

--Rik