Hello, Thank you very much, I applied your patch and I tried to build one of tha packages that I made. Now the libraries are correctly detected when it does the configuration. Unfortunately, it seems that it has the same defect that I got with my patch, because the debuginfo files are not created. The process prints on the console:
*** Info: No debug files, skipping debuginfo subpackage
It seems that both our patches are not good when cygport is called
with the "install" command.
The effect is that after calling a command like "cygport
myscript.cygport install", the "src" directory is not created under
"inst" directory.
So, the next call to "cygport myscript.cygport package" doesn't create
the debuginfo packages because that "src" directory doesn't exist.
Unfortunately, something new happened after applying your patch.
When executing the "package" command, cygport puts inside the source
archive a gigantic patch file with the files created by "compile"
command.
In other words on the console it appears something like this:
>>> Creating source patches
diff: src/rubberband-4.0.0/CYGWIN-PATCHES: Is a directory
_build.x86_64-w64-mingw32/.hgignore | 3
_build.x86_64-w64-mingw32/.ninja_log | 27
_build.x86_64-w64-mingw32/build.ninja
| 234 ++++
_build.x86_64-w64-mingw32/compile_commands.json | 134 ++
_build.x86_64-w64-mingw32/meson-info/intro-benchmarks.json | 1
...etc
I don't know if there are some traps somewhere into the scripts of
cygport, to avoid that it could wrongly add the generated files as
patch files.
In my previous patch, this was not happening because those files were
generated into ${B} so it didn't find anything different inside ${S}.
Perhaps it would be worth to understand why it doesn't copy the
information for debuginfo inside "inst/src". Perhaps it is the same
defect for both and, after solving it, we won't need to worry about
dirty files inside ${S} if they will created inside ${B}.
I attached the script file of the package that I used for this test,
with the hope that it could be helpful to understand the causes of the
problems.This is a package for an audio library called "rubberband",
which is used by Mixxx Virtual DJ software.
You can get the source archive by using the usual download command:
cygport rubberband.cygport download
and then start the creation of the package with the also usual:
cygport rubberband.cygport all
for creating the packages.
These packages use the x86_64-w64-mingw32 cross compiler.
BTW, I take the chance to report something missing into this page:
https://cygwin.github.io/cygport/cygport_in.html
If you look into:
Chapter 3 => Format => Globals
near the various ${S}, ${B}, etc... it is missing the description of ${T}.
Unless I have understood wrong, ${T} points to the "temp" directory,
but its description is missing inside the list of the global
variables.
I hope that all this could be useful.
Sincerely,
Carlo Bramini.
Il giorno mar 18 mar 2025 alle ore 20:36 Jon Turney
<jon.tur...@dronecode.org.uk> ha scritto:
>
> On 17/03/2025 22:26, Jon Turney via Cygwin-apps wrote:
> > On 17/03/2025 09:02, Carlo B. via Cygwin-apps wrote:
> [...]
> >
> > Thanks very much for the simple test case!
> >
> > This is pretty weird. The meson-log.txt file says that running '/usr/
> > bin/x86_64-w64-mingw32-pkg-config --modversion glib-2.0' is failing, but
> > that works fine when run from the command line.
> >
> > After poking at it for a bit, I discovered that the presence of a
> > 'x86_64-w64-mingw32' directory in the working directory seems to be the
> > thing which makes it fail.
> >
> > (So I'm guessing pkgconf does something like look there, rather than in
> > the sysroot, if it exists, although I can't find that documented
> > anywhere, and I don't have time to go diving through the source right now)
> >
> > I guess maybe a fix/workaround would be to change the name of the
> > subdirectory used for the meson build from '${CHOST}' to 'build.
> > ${CHOST}' or similar.
> So something like the attached (which appears to fix things for your
> testcase)...
mingw64-x86_64-rubberband.cygport
Description: Binary data
