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
