[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Porting Summary for Subversion 1.6.2 to OpenVOS 17.0

From: Green, Paul <Paul.Green_at_stratus.com>
Date: Fri, 26 Jun 2009 15:35:57 -0400

Gentle Subversion Developers,

This memo briefly reports on how I ported Subversion 1.6.2 to Stratus
OpenVOS Release 17.0.1aq. OpenVOS started life as a proprietary
operating system but now has a fairly complete POSIX-based software
development environment. I used GCC version 3.4.6 and the standard
OpenVOS POSIX libraries (which we wrote or ported; we don't use glibc).

It almost built and installed without any errors. I was really
impressed. The issues I ran into were obvious and easy to deal with. In
fact, now that I look at the changes, all (but one) of them were in
software that you simply import. I've attached the patch file.

I was only trying to port the svn client. While the server built without
errors, I haven't tested it. I didn't build against Berkeley DB.

1. subversion/Makefile.in

We use separate source directories and build directories. We like to
keep our source directories clean and not modify them. So the notion of
a derived file ("subversion/subversion/libsvn_fs_fs/rep-cache-db.h")
getting added to the SOURCE hierarchy is a source of unhappiness. Given
that you build this "source" file with a shell script (which everyone
who builds subversion already has), and given that it could just as
easily go into the build tree, I don't quite see why it had to go into
the source tree. I changed the Makefile to place it into a directory
that the compiler already searches; it probably isn't quite what you
would have done, but it works for me. (I think the construct I used to
solve this problem is specific to GNU make, but I'm not certain of

2. subversion/apr/network_io/unix/sockopt.c

This release of OpenVOS does not implement SIOCATMARK. There is already
a guard around this code that references the BEOS_R5 macro. So I simply
added the __VOS__ macro alongside it. (I could have had the #if
preprocessor statement test for the existence of SIOCATMARK directly,
since we don't define it, but I stayed with the existing scheme).

3. subversion/apr-util/xml/expat/Makefile.in

As we are keeping "configure" under source control, I commented out the
command that rebuilds it if it appears to be out-of-date. This is a nit.

4. subversion/apr-util/xml/expat/conftools/config.guess

This file is over seven years out-of-date (2002-03-20). I patched it to
add our changes, which have been present since at least 2005-07-08.
Another nit.

5. subversion/serf/Makefile.in

I'm using static linking, not dynamic linking, and the order of the
libraries in the LIBS Makefile variable matters. The original text
searched "-lz -lssl -lcrypto". But since OpenSSL can call the
compression library, the order should be "-lssl -lcrypto -lz".

6. subversion/neon/install-sh

Sadly, our POSIX implementation cannot create a file with a number sign
("#") in its name (as in "#inst.$$#"). I substituted an underscore.

7. subversion/sqlite-amalgamation/sqlite3.c

This program references the legacy utimes() function, which has since
been replaced by the utime() function with a nearly-identical
definition. We don't have utimes, but we do have utime(), so I made the
obvious change.

Thanks for creating and maintaining such a useful product. As someone
who has been writing software for 40+ years, I have to stay that
Subversion has some of the cleanest code I've ever read or ported.


Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen

Received on 2009-06-27 11:31:26 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.