Re: Subversion 1.15.0-rc3 up for testing/signing

On 15. 7. 2026 14:58, Ivan Zhakov wrote:
> On Wed, 15 Jul 2026 at 14:48, Branko Čibej <[email protected]> wrote:
>
>     On 15. 7. 2026 13:32, Ivan Zhakov wrote:
>>     On Tue, 14 Jul 2026 at 18:18, Branko Čibej <[email protected]> wrote:
>>
>>     [...]
>>
>>>         Longer term, we could think about getting to a state where
>>>         our .tar.gz, .tar.bz2, and .zip all have identical content
>>>         (generated once). Otherwise we risk potential
>>>         inconsistencies: for example, if someone on Windows
>>>         downloads subversion-1.14.5.tar.bz2 instead of .zip. And it
>>>         also makes the release process more complicated, because
>>>         there is at least 2x different content to check/verify.
>>
>>         Unix tarballs are libtoolized and contain generated swig
>>         binding code and such. We don't need the libtool bits and
>>         don't support pre-generated bindings in the Windows build, so
>>         there's a reason why contents are somewhat different. And all
>>         the files within the .zip with svn:eol-style=native have CRLF
>>         line endings (that's why I use 'diff -qrw` to compare). The
>>         latter used to be required because 'cl' and 'msdev' and
>>         'cmd.exe' didn't use to like just LF newlines in source and
>>         project files. I suppose that's no longer a concern?
>>
>>     Visual Studio and 'cl' work fine with LF these days. I have
>>     tested 'cmd' and it also works fine, but I won't put my finger on
>>     all possible tools.
>>
>>     With the addition of CMake, separate Windows and Unix tarballs
>>     may no longer hold as an abstraction. Maybe we could just have a
>>     CRLF "Windows" zip and LF "Unix" tar.gz with identical content?
>
>
>     So you would keep the results of 'autogen.sh --release' in the .zip?
>
>
> Maybe I am missing something, but I don't see a problem here.

.tar.gz and tar.bz2 contain generate libtool and configure scripts, and 
also Swig-generated sources, so that building with autotools doesn't 
depend on autoconf/libtool/m4 or Swig or Python.

The .zip doesn't contain any of that. It's obvious why it doesn't need 
the autotools scripts. I'm not sure about Swig-generated sources, nor 
why we don't include those in the .zip.

>     I don't know if the CMake build supports that. The old vcxproj
>     generator doesn't. But the autotools build needs that, otherwise
>     builds depend on m4 and Python and libtoolize etc.
>
> CMake has similar targets.cmake that is generated during tarball 
> creation for the same reason: to not depend on Python.

I know, but that's not the only difference, see above.

> Also I think we should drop support vcxproj support in the long term.

Agreed, but irrelevant to this particular discussion.

-- Brane