On Sun, Oct 20, 2024 at 01:17:11PM +0200, Daniel Sahlberg wrote:
> What I wanted to achieve is that `svn st` doesn't show Makefile.svn as
> modified, just because I want to try out a different version of one of the
> dependencies.

I use a separate working copy for the unix-build directory, such
that changes to Makefile.svn won't get mixed up with changes I might
have sitting in a working copy of svn-trunk.  Does this help?

The layout I would use is:

  mkdir ~/svn
  cd ~/svn
  svn co https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/unix-build
  ln -s unix-build/Makefile.svn
  gmake

The last step will check out svn trunk into ~/svn/svn-trunk, next
to ~/svn/unix-build. I would never modify Makefile.svn in svn-trunk
so it never gets in my way there.

Regarding multi-version support, some dependencies need patches from the
OpenBSD ports tree, usually to fix build issues with libssl or other
libraries. Such patches might not apply to all possible versions of a
dependency, breaking the build for some of them. With this kept in mind,
I don't see a problem with supporting multiple versions of a dependency.
It's also no problem if some versions you want to try out won't build on
OpenBSD. I can fix such things up myself if needed.

We have already dealt with multiple versions of a dependency in Makefile.svn
where necessary by adding each version as a separate set of build rules.
See serf vs. serf-old targets for example (in Makefile.svn before r1905428).
This involves some copy&paste and results in some amount of redundancy,
which is not a problem for me. This file does not need to be beautiful code.

Reply via email to