Re: [PATCH cygport] git.cygclass: Suppress the depth option
On 03/12/2023 21:53, Brian Inglis via Cygwin-apps wrote: On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote: On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote: Implementations that conditionally branch on variables are simple. The proposed retry implementation complicates git.cygclass, but I think it reduces the maintainer's effort. I have created a patch for a retry implementation. Could you review it? Thanks very much to Fujimura-san for all his work on this. Attached is the patch after my edits. I've applied a reheated version of this patch. Hopefully that works well enough, but obviously can be further refined if needed. Looks like straight curl HEAD -I tells you about smart transport if you want a quick check rather than a dry run: $ time curl -ILSs https://repo.or.cz/r/git.git/info/refs?service=git-upload-pack | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $? real 0m0.630s user 0m0.077s sys 0m0.123s 0 $ time curl -ILSs https://github.com/BrianInglis/apt-cyg.git/info/refs?service=git-upload-pack | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $? real 0m0.440s user 0m0.061s sys 0m0.184s 1 Thanks for this. Uh, but it seems like 'git clone --depth 1' works with both of these URLs, so... um... I'm not sure what's going on.
Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS
On 04/02/2024 16:30, Christian Franke via Cygwin-apps wrote: Jon Turney wrote: On 02/02/2024 16:13, Christian Franke via Cygwin-apps wrote: _FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc 13.2.1 test release. Silently falls back to level 2 if level 3 is unsupported (older headers or gcc) or to level 0 if unsupported at all (C++, clang). Thanks. I applied this. I'm thinking I want to try to do another cygport release fairly soonish, so please feel free to remind me about any other patches by you (or others) which I need to look at before then. Possibly some initial SOURCE_DATE_EPOCH support: https://sourceware.org/pipermail/cygwin-apps/2023-August/043108.html I've applied this (and I think I might have caught up on most of the pending patches...) It would be nice to have some sort of test, since there's no coverage with SOURCE_DATE_EPOCH defined at the moment. Even if we just verify that an existing test continues to build without problems with it defined, that would be a good start, let alone verifying that it actually sets timestamps as expected...
Re: cygport may not create debug info if top directory contains a symlink
On 30/10/2023 16:37, Christian Franke via Cygwin-apps wrote:
Jon Turney wrote:
On 20/09/2023 11:58, Christian Franke via Cygwin-apps wrote:
Brian Inglis wrote:
On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:
Brian Inglis wrote:
On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:
On 16/09/2023 15:17, Christian Franke via Cygwin wrote:
Found during tests of busybox package:
If the path of the top build directory contains a symlink and
the project's build scripts normalize pathnames, no debug info
is created by cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler
is run with the real source path.
I think that there was some historical bug with gcc where a
relative path for the old path in this mapping wasn't correctly
handled, which is why were using an absolute path here at all.
So changing it to something like [1] (if that works), might be
better.
[1]
https://github.com/jon-turney/cygport/commit/4175d456a9184c5cdebd8bfb4b5ba30583cedd66
Should bin/cygport.in:534: not have $B between the == as in line 531:
declare ${flags}+=" -fdebug-prefix-map=${B}=/usr/src/debug/${PF}"
...
declare ${flags}+=" -fdebug-prefix-map==/usr/src/debug/${PF}"
or be hoist above the condition if identical, unless that is some
undocumented default for cwd?
I guess the == without ${B} is intentional because it makes the debug
source path relative to ${B} as lines 535-536 also do.
[...]>
(It's unclear to me how gcc compares paths to apply this mapping. If
it's a literal string prefix, rather than on some (semi-)canonicalized
path, then we're maybe going to lose here sometimes, depending on the
vagaries of the build-system, unless we list all of relative,
absolute, and canonical absolute paths?)
(But then maybe we can push dealing with or indicating which of those
is correct off onto the individual cygport?)
Adding this if "$(cd ${S} && pwd -P)" != "${S}" should IMO be safe:
-fdebug-prefix-map=$(cd ${B} && pwd -P)=/usr/src/debug/${PF}
-fdebug-prefix-map=$(cd ${S} && pwd -P)=/usr/src/debug/${PF}
(or use realpath)
So it seems there's a new flag '-fcanon-prefix-map' in GCC 13, which
looks like it maybe solves this problem.
