[PATCH] Cygport: generate object files into {B} instead of ${S}/*_w64-mingw32

[Jon Turney]

On 21/02/2025 10:40, Carlo B. via Cygwin-apps wrote:
> Hello,
> I'm doing packages for CYGWIN, with updated or missing libraries that
> you can find here:
> 
> https://github.com/carlo-bramini/packages-cygwin
> 
> While doing this task, I got troubles when using Cygport with Meson.
> If I create packages for CYGWIN, x86_64 or i686, I works fine.
> But if I create packages by using cross compilers, in other words
> NOARCH stuff, it doesn't work.
> To be more precise, existing libraries and tools into the sysroot are not found.

Thanks.

Hmm... I don't quite understand why this change has the effect of 
resolving this problem.

Can you explain?

> This is an example output when building librubberband with MinGW cross
> compilers:
> 
> Run-time dependency fftw3 found: NO (tried pkgconfig and cmake)
> Run-time dependency sleef found: NO (tried pkgconfig and cmake)
> Run-time dependency sleefdft found: NO (tried pkgconfig and cmake)
> Run-time dependency samplerate found: NO (tried pkgconfig and cmake)
> Run-time dependency speexdsp found: NO (tried pkgconfig and cmake)
> 
> I did a correction to Meson.cygclass and now it works like this:
> 
> Run-time dependency fftw3 found: YES 3.3.5
> Run-time dependency sleef found: NO (tried pkgconfig and cmake)
> Run-time dependency sleefdft found: NO (tried pkgconfig and cmake)
> Run-time dependency samplerate found: YES 0.1.8
> Run-time dependency speexdsp found: YES 1.2rc3
> 
> After applying attached patch, the object files will be generated
> inside ${B} rather than into a subdir of ${S}.
> I have found no other way to make it working.
> But afterall, ${B} exists for this purpose and I don't see a good
> reason because ${S} should be polluted with object files.

Yeah, it would be nice if meson worked in the same way as the other 
build systems.

Unfortunately, this wasn't written by me, and I'd need to go digging 
through history to discover all the details.

If I recall correctly, it's related to how we use the gcc options 
-fdebug-prefix-map or -ffile-prefix-map.

(See the thread starting at [1] for a bit of discussion around these 
options)

Those work (or at least, worked) by string prefix substitution, rather 
than path manipulation, and the forms of the paths passed to the 
compiler by (the ninja file generated by) meson aren't amenable the same 
simple manipulations relative to ${B} as other build systems (e.g. 
autotools).


So I guess the first question to ask is if you're still getting correct 
debuginfo package generation with this patch?


[1] https://cygwin.com/pipermail/cygwin-apps/2023-September/043185.html