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.