>> > (snipping most content)
>> > > When I was was doing that, I solved the problem with uname with a
>> > > little patch by adding ifdef over release_name_from_uname() invocation
>> > > in sysinfo.c:
>> > >
>> > > [[[
>> > > Index: subversion/libsvn_subr/sysinfo.c
>> > > ===================================================================
>> > > --- subversion/libsvn_subr/sysinfo.c (revision 1919186)
>> > > +++ subversion/libsvn_subr/sysinfo.c (working copy)
>> > > @@ -646,8 +646,12 @@
>> > > static const char *
>> > > linux_release_name(apr_pool_t *pool)
>> > > {
>> > > - const char *uname_release = release_name_from_uname(pool);
>> > > + const char *uname_release;
>> > >
>> > > +#if HAVE_UNAME
>> > > + uname_release = release_name_from_uname(pool);
>> > > +#endif
>> > (snipping the rest...)
>> >
>> > If HAVE_UNAME is not defined, then uname_release will point to
>> > undefined address? I think we need some default string. Perhaps
>> > "unknown"?
>>
>> Hi,
>>
>> Yes it will. However, as I understand the implementation of
>> release_name_from_uname(), it returns NULL if the uname cannot be
>> recognized (see sysinfo.c:312).
>>
>> Additionally, the svn_sysinfo__release_name function (which will
>> return that NULL) could do that, because (sysinfo.h:41):
>>
>> [[[
>> Return the release name (i.e., marketing name) of the running
>> system, or NULL if it's not available.
>>
>> All allocations are done in POOL.
>> ]]]
>>
>> However, "unknown" might be better than NULL...
>>
> Actually I just looked at the code (I probably should have looked before my
> "unknown" reply!!) and if uname_release is NULL then near the end of the
> function we return release_name instead. If we assign "unknown" to
> uname_release then we will mess up this logic.
>
> Therefore IMO it would be a more correct fix to wrap most of the body of
> release_name_from_uname() in #if HAVE_UNAME so that that function will return
> NULL if uname() is not available, then leave the call site function as is.
Hi,
I made the most fixes suggested from this thread. Now the project
compiles correctly on Linux and also the tests are passing (except one
which doesn't work due to different build layouts and the Python tests
are not yet running). It still needs some testing and improvement. I'd
appreciate any feedback.
Additionally, I tried to compile with CMake on Mac OS and it worked
correctly without any modifications!! I was so excited that it
succeeded!
Regarding the "unknown" problem: I checked what the svn --version
shows when there is no uname; it will be "unknown-unknown-unknown" if
the uname is NULL. I tried to implement the #if HAVE_UNAME check
inside the body, but other similar checks are done similarly to the
code I suggested, for example, the svn_sysinfo__canonical_host
function. Additionally, I svn-diff'd the svn --version commands from
Subversion installed from apt-get and compiled with CMake -- they
are almost the same (excepting minor differences between different
versions).
(Little fix to the code I initially suggested: I forgot to add
initialization of uname_release to NULL, so it should be there, I
forgot to add it):
Finally, after more exploring the build system on Unix platforms and
trying the CMake on them, I thought that the CMake build system could
be also recommended for Unix (of course when it is ready for this).
The main reason for this is that we will only need to support a single
build system across all possible platforms. This means we will only
have to implement features and utilities, such as dependency
searching, once, while ensuring cross-platform support. For example,
this approach could prevent scenarios where a feature is implemented
for Linux, but then requires fixes for the Windows build system.
Additionally, nowadays CMake is considered more modern than autoconf,
offering numerous advanced features for developers, packagers, and
users. It could sometimes work faster and be more configurable than
autoconf. However, this is just my personal opinion, and some
individuals may still prefer autoconf instead, so...
What do you think?
Thanks!
--
Timofei Zhakov
