You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2017/08/09 21:40:02 UTC
errorcode.inc in tarballs
I recently modified release.py and this has meant I have been recreating
old tarballs to test my changes. This has highlighted the file
subversion/libsvn_subr/errorcode.inc
which is generated by gen-make.py, has content that is produced via
Python's errno module with the result that the tarball content depends
on the Python version used to roll the tarball.
When I recreate 1.9.0-rc2 I see this difference:
diff -r subversion-1.9.0-rc2/subversion/libsvn_subr/errorcode.inc subversion-1.9
.0-rc2-orig/subversion/libsvn_subr/errorcode.inc
99c99
< { 95, "ENOTSUP" },
---
> { 95, "EOPNOTSUPP" },
To an extent the change is trivial, this code is only used in SVN_DEBUG
builds and even then it doesn't have much effect on how Subversion
works.
Arguably more important is having our tarballs be reproducible. These
symbolic names are a bit tricky to generate and the choice of python
means it has be done by gen-make.py rather than configure. There are
comments in gen_base.py about this. There is also the question about
how portable these symbolic names are to other systems, i.e. Windows.
I'm considering a --release flag for gen-make.py that omits this
information from the file and thus the tarball.
--
Philip
Re: errorcode.inc in tarballs
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Thu, 10 Aug 2017 11:04 +0200:
> On 09.08.2017 23:40, Philip Martin wrote:
> > To an extent the change is trivial, this code is only used in SVN_DEBUG
> > builds and even then it doesn't have much effect on how Subversion
> > works.
> >
> > Arguably more important is having our tarballs be reproducible. These
> > symbolic names are a bit tricky to generate and the choice of python
> > means it has be done by gen-make.py rather than configure. There are
> > comments in gen_base.py about this. There is also the question about
> > how portable these symbolic names are to other systems, i.e. Windows.
> >
> > I'm considering a --release flag for gen-make.py that omits this
> > information from the file and thus the tarball.
>
> Since OS-specific error codes are, by definition, OS-specific, it's more
> or less impossible to generate errorcode.inc on one platform and use it
> on another. Even "POSIX" errno values are not consistent across platforms.
>
> Would be better to generate this header at build time ... but to do that
> in a cross-platform manner, we'd have to write a C program to do that.
And to not break cross-builds, we'll want to limit ourselves to using the
preprocessor, compiler, and linker, but not to running any compiled C program.
That said, I agree with Philip: this functionality is only used by maintainer
mode builds, and even then it's only used to prettify error messages, so it's
easier to disable it where we can't easily provide it.
These two together suggest we should disable that functionality on
cross-builds, too. This functionality is currently implemented pre-configure,
in gen-make.py, because configure doesn't require Python, but it seems to make
perfect sense to move this functionality to configure provided that it be
guarded with:
if (maintainer mode); then
if cross building;
build an empty/dummy error-code.inc;
else
build error-code.inc;
endif
else
(nothing)
fi
?
Re: errorcode.inc in tarballs
Posted by James McCoy <ja...@jamessan.com>.
On Aug 10, 2017 15:29, "Philip Martin" <ph...@codematters.co.uk> wrote:
Branko Čibej <br...@apache.org> writes:
> Would be better to generate this header at build time ... but to do that
> in a cross-platform manner, we'd have to write a C program to do that.
Even that is hard, I know of no easy way for C code to convert an error
number into a symbolic name. Going from names to numbers would require
us to know, and hard-code, the names.
One way to convert numbers to names is to parse the C header, which on
my Linux system involves following several include directives to find
the underlying files:
awk '/#define\sE.*[0-9]/{printf "{%s, \"%s\"},\n", $3, $2 }' \
/usr/include/asm-generic/errno-base.h \
/usr/include/asm-generic/errno.h
The approach that moreutils'[0] errno utility takes[1] looks useful.
[0]: https://joeyh.name/code/moreutils/
[1]: https://sources.debian.net/src/moreutils/0.60-1/Makefile/#L41-L45 to
generate the array consumed by
https://sources.debian.net/src/moreutils/0.60-1/errno.c/#L33-L38
Cheers,
James
Re: errorcode.inc in tarballs
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Čibej <br...@apache.org> writes:
> Would be better to generate this header at build time ... but to do that
> in a cross-platform manner, we'd have to write a C program to do that.
Even that is hard, I know of no easy way for C code to convert an error
number into a symbolic name. Going from names to numbers would require
us to know, and hard-code, the names.
One way to convert numbers to names is to parse the C header, which on
my Linux system involves following several include directives to find
the underlying files:
awk '/#define\sE.*[0-9]/{printf "{%s, \"%s\"},\n", $3, $2 }' \
/usr/include/asm-generic/errno-base.h \
/usr/include/asm-generic/errno.h
--
Philip
Re: errorcode.inc in tarballs
Posted by Branko Čibej <br...@apache.org>.
On 09.08.2017 23:40, Philip Martin wrote:
> I recently modified release.py and this has meant I have been recreating
> old tarballs to test my changes. This has highlighted the file
>
> subversion/libsvn_subr/errorcode.inc
>
> which is generated by gen-make.py, has content that is produced via
> Python's errno module with the result that the tarball content depends
> on the Python version used to roll the tarball.
>
> When I recreate 1.9.0-rc2 I see this difference:
>
> diff -r subversion-1.9.0-rc2/subversion/libsvn_subr/errorcode.inc subversion-1.9
> .0-rc2-orig/subversion/libsvn_subr/errorcode.inc
> 99c99
> < { 95, "ENOTSUP" },
> ---
>> { 95, "EOPNOTSUPP" },
> To an extent the change is trivial, this code is only used in SVN_DEBUG
> builds and even then it doesn't have much effect on how Subversion
> works.
>
> Arguably more important is having our tarballs be reproducible. These
> symbolic names are a bit tricky to generate and the choice of python
> means it has be done by gen-make.py rather than configure. There are
> comments in gen_base.py about this. There is also the question about
> how portable these symbolic names are to other systems, i.e. Windows.
>
> I'm considering a --release flag for gen-make.py that omits this
> information from the file and thus the tarball.
Since OS-specific error codes are, by definition, OS-specific, it's more
or less impossible to generate errorcode.inc on one platform and use it
on another. Even "POSIX" errno values are not consistent across platforms.
Would be better to generate this header at build time ... but to do that
in a cross-platform manner, we'd have to write a C program to do that.
-- Brane