There are no errors when I run /.configure and it seems to find all
the mandatory dependancies and a few non-mandatories, too.
There are no warnngs / errors.
There are a few warning about functions being deprecated, Eg.;
subversion/libsvn_ra/compat.c: In function ‘prev_log_path’:
subversion/libsvn_ra/compat.c:163: warning: ‘svn_path_join’ is
deprecated (declared at ./subversion/include/svn_path.h:108)
and this block that I have no idea about;
ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(config_win.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(debug.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crashrpt.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_crypto.o) has no symbols
ranlib: file: .libs/libsvn_subr-1.a(win32_xlate.o) has no symbols
Otherwise make "seems" to run fine and dandy.
And I am not too sure why the difference... but it took only a few
minutes this time around for make and make install to complete.
I "assume" that it is because "other stuff" is now compile that
previously wan't? But I thought that was all taken care of when they
libraries were installed via macports...
Gavin.
On 09/11/2009, at 23:22 , Julian Foad wrote:
> Gavin Baumanis wrote:
>> I have finally managed to compile Subversion on my Mac - wahoo for
>> me!
>
> Great!
>
>> It took 50 minutes to compile simply using ./configure;make;make
>> install;
>> Is this "about" normal? - not ever having compiled it before I have
>> no
>> point of reference for whether this is a long time or not.
>
> I haven't tried it on a Mac but that sounds very long. It takes my
> machine less than 5 minutes.
>
>> The summary says that only 5 tests failed, but there are most
>> certainly more than 5 failures listed.
>> So why is there is a discrepancy, and which of these two outputs
>> should I believe?
>
> Ah, that's a bug in the test suite: all of your Python test files are
> completely failing to run, and for each of those the test suite prints
> "authz_tests.py [33/77].............FAILURE", but it doesn't count
> that
> failure in the summary.
>
> I'll post a patch to try to fix that.
>
>> And while I do recall specific "test failures" mentioned at times
>> within the dev mailing list;
>> Is there a "protocol" to follow if you notice a test failure?
>>
>> I guess it is going to be an experience "thing" - but how do you know
>> what test failures are important and which aren't?
>> Or is it a case of they're all important?
>
> They are all important. The project policy is for all tests to be
> passing (or marked XFAIL etc) at all times. When there is a failure,
> it
> is usually your local mods or your local set-up that are the problem.
> Sometimes there are a few failures that are hard to debug and exist
> for
> up to a few weeks, but we try hard to avoid that because it makes
> everyone's life difficult because then they don't know whether
> failures
> are their fault or not.
>
> So you need to look for the cause of your failures. Start with either
> the first C test that fails or the first Python test that fails,
> depending on which you are more comfortable with debugging. For the
> Python tests, look in "tests.log" which was created by running the
> test
> suite, or run an individual test in "verbose" mode:
>
> cd subversion/tests/cmdline
> ./authz_tests.py 1 --verbose
>
> First, you should probably look through the output of "./configure"
> and
> see if there were any failures or warnings there, because maybe part
> of
> your build failed.
>
> - Julian
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415764
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415904
Received on 2009-11-09 21:51:22 CET