On 09/10/17 13:41, Eli Schwartz wrote: > On 10/08/2017 09:53 AM, Allan McRae wrote: >> On 08/10/17 16:38, Eli Schwartz wrote: >>> In commit 8b0d59b83a60eb504567590346119fe4cd891cad support was added for >>> storing the source files of binaries in debug packages. This made use of >>> the debugedit program which is part of the RPM package manager, which is >>> not very standalone. >>> >>> The same effect can be achieved using -fdebug-prefix-map, an option >>> accepted by both the gcc and clang compilers which modifies how the >>> compiler itself stores the references to the source files rather than >>> requiring us to later edit the produced binaries. This also removes the >>> dependency on external programs like debugedit. >>> >>> As a result of this change, source files will only be effectively added >>> for programs which actually use the exported CFLAGS. This is a reasonable >>> tradeoff as we expect our CFLAGS to be used rather than ignored. Upstream >>> software which do not produce useful debug packages are expected to fix >>> their build systems to respect the environment CFLAGS. >>> >>> Signed-off-by: Eli Schwartz <[email protected]> >> >> This patch is doing many things at once. >> >> 1) Add the DBGSRCDIR configuration option >> 2) Add -fdebug-prefix-map >> 3) What ever the changes in the while loop are... >> (at first glance they seem wrong) >> >> Please submit as separate patches. > > I can split it into multiple patches, though these really seem to me to > all be one thing. Or at least the changes to the while loop are a direct > result of modifying the debug prefixes at build time rather than after > that while loop during strip_file(). Using -fdebug-prefix-map means > source_files() no longer reports what it originally did when you > authored commit 8b0d59b83a60eb504567590346119fe4cd891cad. I think I > correctly modified that function to work in reverse but I could be wrong > as I never did take a close look at what it does. > > I suppose I could split out the DBGSRCDIR configuration option you asked > for, but I'd prefer to keep the other bits together as this ensures > bisecting each patch still works as expected. >
Yes - keep #2 and #3 together. I did not realise what the changes in the while loop did. Allan
