Help needed with gobject-introspection

Help needed with gobject-introspection

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

I would like to adopt gimp and related packages.  At the moment I'm having 
trouble with babl, which is needed for gegl0.4, which is needed for gimp.  The 
problem involves gobject-introspection.

If I disable introspection, the build works fine.  This would be OK, since babl 
has been built without introspection for several years.  But then the gegl0.4 
build complains about the missing babl introspection files, so I would have to 
disable introspection there too, which hasn't been done in the past.

So my preference is to figure out what the problem is and get the babl build 
working with introspection.  I'm attaching my cygport file and patch.

Here's the failing command...

/usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT --no-libtool 
--namespace=Babl --nsversion=0.1 --warn-all --output babl/Babl-0.1.gir 
--c-include=babl.h '--identifier-filter-cmd=/usr/bin/python3 
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
-DBABL_IS_BEING_COMPILED 
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
-I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -I./. 
-I../. -I./babl/base/. -I../babl/base/. 
--filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
--cflags-begin -fno-unsafe-math-optimizations -Wdeclaration-after-statement 
-Winit-self -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition 
-Wpointer-arith -mmmx -msse -mfpmath=sse -I./. -I../. -I./babl/base/. 
-I../babl/base/. --cflags-end --library babl-0.1 
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
--extra-library=m --extra-library=dl --extra-library=lcms2

...and the error message:

g-ir-scanner: link: gcc -o 
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
-ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-fstack-protector-strong --param=ssp-buffer-size=4 
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
-fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
-L. -lbabl-0.1 -lm -ldl -llcms2 
-L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
-Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
-lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
ERROR: can't resolve libraries to shared libraries: babl-0.1

I don't understand the error message, because the command line contains

   -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl

and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll.  I even 
tried adding that directory to my PATH to make sure the right cygbabl-0.1-0.dll 
would be found, but that didn't help.

Can anyone help?

Thanks.

Ken

[-- Attachment #2: babl.cygport --]
[-- Type: text/plain, Size: 1143 bytes --]

inherit meson

NAME="babl"
VERSION=0.1.74
RELEASE=1
CATEGORY="Libs"
SUMMARY="Any-to-any pixel format conversion library"
DESCRIPTION="Babl is a dynamic, any to any, pixel format conversion library.
It provides conversions between the myriad of buffer types images can be
stored in. Babl doesn't only help with existing pixel formats, but also
facilitates creation of new and uncommon ones."
HOMEPAGE="http://www.gegl.org/babl/"
SRC_URI="http://download.gimp.org/pub/babl/${VERSION%.*}/babl-${VERSION}.tar.xz"

PATCH_URI="0.1.74-cygwin.patch"

PKG_NAMES="libbabl0.1_0 libbabl-devel" # girepository-Babl0.1 vala-babl0.1"
libbabl0_1_0_SUMMARY="${SUMMARY} (runtime)"
libbabl0_1_0_CONTENTS="usr/bin/*-0.1-0.dll usr/lib/babl-0.1/ usr/share/doc/"
libbabl_devel_SUMMARY="${SUMMARY} (development)"
libbabl_devel_CONTENTS="usr/include/ usr/lib/lib* usr/lib/pkgconfig/"
girepository_Babl0_1_SUMMARY="${SUMMARY} (GObject Introspection)"
girepository_Babl0_1_CONTENTS="usr/*/gir*/Babl-0.1.*"
vala_babl0_1_SUMMARY="${SUMMARY} (Vala bindings)"
vala_babl0_1_CONTENTS="usr/share/vala/"

CYGMESON_ARGS="-Dwith-docs=false"
# CYGMESON_ARGS+=" -Denable-gir=false"

[-- Attachment #3: 0.1.74-cygwin.patch --]
[-- Type: text/plain, Size: 1033 bytes --]

--- origsrc/babl-0.1.74/meson.build	2020-01-12 18:26:51.000000000 -0500
+++ src/babl-0.1.74/meson.build	2020-05-18 18:11:58.729959300 -0400
@@ -104,7 +104,6 @@ host_os = host_machine.system()
 message('Host os: ' + host_os)
 
 platform_win32 = (host_os.startswith('mingw') or
-                  host_os.startswith('cygwin') or
                   host_os.startswith('windows'))
 
 platform_osx = host_os.startswith('darwin')
@@ -118,7 +117,7 @@ platform_android = host_os.contains('and
 
 path_sep = ( platform_win32 ? ';'     : ':' )
 dirs_sep = ( platform_win32 ? '\\\\'  : '/' )
-if platform_win32
+if platform_win32 or host_os.startswith('cygwin')
   lib_ext = '.dll'
 elif platform_osx
   lib_ext = '.dylib'
@@ -145,7 +144,6 @@ build_os = build_machine.system()
 message('Build os: ' + build_os)
 
 build_platform_win32 = (build_os.startswith('mingw') or
-                        build_os.startswith('cygwin') or
                         build_os.startswith('windows'))
 
 # Only run cross compile objects if we have exe wrapper

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
> I would like to adopt gimp and related packages.  At the moment I'm having 
> trouble with babl, which is needed for gegl0.4, which is needed for gimp.  The 
> problem involves gobject-introspection.
> 
> If I disable introspection, the build works fine.  This would be OK, since babl 
> has been built without introspection for several years.  But then the gegl0.4 
> build complains about the missing babl introspection files, so I would have to 
> disable introspection there too, which hasn't been done in the past.
> 
> So my preference is to figure out what the problem is and get the babl build 
> working with introspection.  I'm attaching my cygport file and patch.
> 
> Here's the failing command...
> 
> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT --no-libtool 
> --namespace=Babl --nsversion=0.1 --warn-all --output babl/Babl-0.1.gir 
> --c-include=babl.h '--identifier-filter-cmd=/usr/bin/python3 
> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
> -DBABL_IS_BEING_COMPILED 
> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -I./. 
> -I../. -I./babl/base/. -I../babl/base/. 
> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
> --cflags-begin -fno-unsafe-math-optimizations -Wdeclaration-after-statement 
> -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition 
> -Wpointer-arith -mmmx -msse -mfpmath=sse -I./. -I../. -I./babl/base/. 
> -I../babl/base/. --cflags-end --library babl-0.1 
> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
> --extra-library=m --extra-library=dl --extra-library=lcms2
> 
> ...and the error message:
> 
> g-ir-scanner: link: gcc -o 
> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -fstack-protector-strong --param=ssp-buffer-size=4 
> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
> -L. -lbabl-0.1 -lm -ldl -llcms2 
> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
> ERROR: can't resolve libraries to shared libraries: babl-0.1
> 
> I don't understand the error message, because the command line contains
> 
>    -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
> 
> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll.  I even 
> tried adding that directory to my PATH to make sure the right cygbabl-0.1-0.dll 
> would be found, but that didn't help.

By the way, in case you're wondering why I disabled the building of docs, it's 
because I was getting a build failure there too.  I don't know if this is 
related to the introspection failure.  The failing command there is

/usr/bin/meson --internal exe --unpickle 
/tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat
cp: target 'docs/index.html.tmp' is not a directory

I don't know why it's not showing me the actual cp command that fails.  The 
corresponding information in docs/meson.build is

Reference_html = custom_target('Reference.html',
   input : [
     'Reference-static.html',
     'toc',
     index_html_tmp,
   ],
   output: [ 'Reference.html', ],
   command: [
     env_bin,
     'cp', '@INPUT0@', '@OUTPUT@',
     '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
     '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
   ],
   build_by_default: true,
)

There are several such custom targets in the file, and for all except this one, 
I see the actual cp command in the log.  This is the only one for which meson 
generates a 'meson --unpickle' command instead of a cp command.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>> I would like to adopt gimp and related packages.  At the moment I'm 
>> having trouble with babl, which is needed for gegl0.4, which is needed 
>> for gimp.  The problem involves gobject-introspection.
>>
>> If I disable introspection, the build works fine.  This would be OK, 
>> since babl has been built without introspection for several years.  
>> But then the gegl0.4 build complains about the missing babl 
>> introspection files, so I would have to disable introspection there 
>> too, which hasn't been done in the past.
>>
>> So my preference is to figure out what the problem is and get the babl 
>> build working with introspection.  I'm attaching my cygport file and 
>> patch.
>>
>> Here's the failing command...
>>
>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>> babl/Babl-0.1.gir --c-include=babl.h 
>> '--identifier-filter-cmd=/usr/bin/python3 
>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>> -DBABL_IS_BEING_COMPILED 
>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>> --cflags-begin -fno-unsafe-math-optimizations 
>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx 
>> -msse -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. 
>> --cflags-end --library babl-0.1 
>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>
>> ...and the error message:
>>
>> g-ir-scanner: link: gcc -o 
>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>> -fstack-protector-strong --param=ssp-buffer-size=4 
>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
>> -lglib-2.0 -lintl
>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>
>> I don't understand the error message, because the command line contains
>>
>>    
>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>
>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll.  
>> I even tried adding that directory to my PATH to make sure the right 
>> cygbabl-0.1-0.dll would be found, but that didn't help.

This might possibly be related to the problem described in the comment for:

https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4

> By the way, in case you're wondering why I disabled the building of 
> docs, it's because I was getting a build failure there too.  I don't 
> know if this is related to the introspection failure.  The failing 
> command there is
> 
> /usr/bin/meson --internal exe --unpickle 
> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
> 
> cp: target 'docs/index.html.tmp' is not a directory
> 
> I don't know why it's not showing me the actual cp command that fails.  

I believe it's is an infelicity in meson that it doesn't echo the actual 
failing command here.

Noted here: 
https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838

> The corresponding information in docs/meson.build is
> 
> Reference_html = custom_target('Reference.html',
>    input : [
>      'Reference-static.html',
>      'toc',
>      index_html_tmp,
>    ],
>    output: [ 'Reference.html', ],
>    command: [
>      env_bin,
>      'cp', '@INPUT0@', '@OUTPUT@',
>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>    ],
>    build_by_default: true,
> )
> 
> There are several such custom targets in the file, and for all except 
> this one, I see the actual cp command in the log.  This is the only one 
> for which meson generates a 'meson --unpickle' command instead of a cp 
> command.

Yeah, I wasn't expecting it to use this method of executing the command 
line (storing it in a pickle and then using a python wrapper to execute 
it) to be used except on Windows, so I'll have to take a more detailed 
look at why that's happening.

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/21/2020 9:24 AM, Jon Turney wrote:
> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>> I would like to adopt gimp and related packages.  At the moment I'm having 
>>> trouble with babl, which is needed for gegl0.4, which is needed for gimp.  
>>> The problem involves gobject-introspection.
>>>
>>> If I disable introspection, the build works fine.  This would be OK, since 
>>> babl has been built without introspection for several years. But then the 
>>> gegl0.4 build complains about the missing babl introspection files, so I 
>>> would have to disable introspection there too, which hasn't been done in the 
>>> past.
>>>
>>> So my preference is to figure out what the problem is and get the babl build 
>>> working with introspection.  I'm attaching my cygport file and patch.
>>>
>>> Here's the failing command...
>>>
>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT --no-libtool 
>>> --namespace=Babl --nsversion=0.1 --warn-all --output babl/Babl-0.1.gir 
>>> --c-include=babl.h '--identifier-filter-cmd=/usr/bin/python3 
>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>> -DBABL_IS_BEING_COMPILED 
>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>> --cflags-begin -fno-unsafe-math-optimizations -Wdeclaration-after-statement 
>>> -Winit-self -Wmissing-declarations -Wmissing-prototypes 
>>> -Wold-style-definition -Wpointer-arith -mmmx -msse -mfpmath=sse -I./. -I../. 
>>> -I./babl/base/. -I../babl/base/. --cflags-end --library babl-0.1 
>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>
>>> ...and the error message:
>>>
>>> g-ir-scanner: link: gcc -o 
>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -fstack-protector-strong --param=ssp-buffer-size=4 
>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>
>>> I don't understand the error message, because the command line contains
>>>
>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>>
>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I even 
>>> tried adding that directory to my PATH to make sure the right 
>>> cygbabl-0.1-0.dll would be found, but that didn't help.
> 
> This might possibly be related to the problem described in the comment for:
> 
> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
> 
> 
>> By the way, in case you're wondering why I disabled the building of docs, it's 
>> because I was getting a build failure there too.  I don't know if this is 
>> related to the introspection failure.  The failing command there is
>>
>> /usr/bin/meson --internal exe --unpickle 
>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>
>> cp: target 'docs/index.html.tmp' is not a directory
>>
>> I don't know why it's not showing me the actual cp command that fails. 
> 
> I believe it's is an infelicity in meson that it doesn't echo the actual failing 
> command here.
> 
> Noted here: https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
> 
>> The corresponding information in docs/meson.build is
>>
>> Reference_html = custom_target('Reference.html',
>>    input : [
>>      'Reference-static.html',
>>      'toc',
>>      index_html_tmp,
>>    ],
>>    output: [ 'Reference.html', ],
>>    command: [
>>      env_bin,
>>      'cp', '@INPUT0@', '@OUTPUT@',
>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>    ],
>>    build_by_default: true,
>> )
>>
>> There are several such custom targets in the file, and for all except this 
>> one, I see the actual cp command in the log.  This is the only one for which 
>> meson generates a 'meson --unpickle' command instead of a cp command.
> 
> Yeah, I wasn't expecting it to use this method of executing the command line 
> (storing it in a pickle and then using a python wrapper to execute it) to be 
> used except on Windows, so I'll have to take a more detailed look at why that's 
> happening.

Thanks.  FWIW, the recipe for building docs/Reference.html translates to

   /usr/bin/env \
      cp ../docs/Reference-static.html docs/Reference.html \
       && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
       && ../docs/tools/xml_insert.sh \
	     docs/Reference.html BablBase docs/index.html.tmp

This succeeds when run manually in the build directory.  So something must have 
gone wrong in the pickling/unpickling process.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
> 
> 
> On 5/21/2020 9:24 AM, Jon Turney wrote:
>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>> I would like to adopt gimp and related packages.  At the moment I'm 
>>>> having trouble with babl, which is needed for gegl0.4, which is 
>>>> needed for gimp. The problem involves gobject-introspection.
>>>>
>>>> If I disable introspection, the build works fine.  This would be OK, 
>>>> since babl has been built without introspection for several years. 
>>>> But then the gegl0.4 build complains about the missing babl 
>>>> introspection files, so I would have to disable introspection there 
>>>> too, which hasn't been done in the past.
>>>>
>>>> So my preference is to figure out what the problem is and get the 
>>>> babl build working with introspection.  I'm attaching my cygport 
>>>> file and patch.
>>>>
>>>> Here's the failing command...
>>>>
>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>> -DBABL_IS_BEING_COMPILED 
>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>> --cflags-begin -fno-unsafe-math-optimizations 
>>>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>>>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx 
>>>> -msse -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>> --cflags-end --library babl-0.1 
>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>>
>>>> ...and the error message:
>>>>
>>>> g-ir-scanner: link: gcc -o 
>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>> -ggdb -O2 -pipe -Wall -Werror=format-security 
>>>> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong 
>>>> --param=ssp-buffer-size=4 
>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
>>>> -lglib-2.0 -lintl
>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>
>>>> I don't understand the error message, because the command line contains
>>>>
>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>
>>>>
>>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. 
>>>> I even tried adding that directory to my PATH to make sure the right 
>>>> cygbabl-0.1-0.dll would be found, but that didn't help.
>>
>> This might possibly be related to the problem described in the comment 
>> for:
>>
>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
>>
>>
>>> By the way, in case you're wondering why I disabled the building of 
>>> docs, it's because I was getting a build failure there too.  I don't 
>>> know if this is related to the introspection failure.  The failing 
>>> command there is
>>>
>>> /usr/bin/meson --internal exe --unpickle 
>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>
>>> cp: target 'docs/index.html.tmp' is not a directory
>>>
>>> I don't know why it's not showing me the actual cp command that fails. 
>>
>> I believe it's is an infelicity in meson that it doesn't echo the 
>> actual failing command here.
>>
>> Noted here: 
>> https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>
>>> The corresponding information in docs/meson.build is
>>>
>>> Reference_html = custom_target('Reference.html',
>>>    input : [
>>>      'Reference-static.html',
>>>      'toc',
>>>      index_html_tmp,
>>>    ],
>>>    output: [ 'Reference.html', ],
>>>    command: [
>>>      env_bin,
>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>    ],
>>>    build_by_default: true,
>>> )
>>>
>>> There are several such custom targets in the file, and for all except 
>>> this one, I see the actual cp command in the log.  This is the only 
>>> one for which meson generates a 'meson --unpickle' command instead of 
>>> a cp command.
>>
>> Yeah, I wasn't expecting it to use this method of executing the 
>> command line (storing it in a pickle and then using a python wrapper 
>> to execute it) to be used except on Windows, so I'll have to take a 
>> more detailed look at why that's happening.
> 
> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
> 
>    /usr/bin/env \
>       cp ../docs/Reference-static.html docs/Reference.html \
>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
>        && ../docs/tools/xml_insert.sh \
>           docs/Reference.html BablBase docs/index.html.tmp
> 
> This succeeds when run manually in the build directory.  So something 
> must have gone wrong in the pickling/unpickling process.


patching 
/usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
something like this might shed some light:

--- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
+++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
@@ -57,6 +57,8 @@
                  ['Z:' + p for p in exe.extra_paths] + 
child_env.get('WINEPATH', '').split(';')
              )

+    print(cmd_args)
+
      p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
                           close_fds=False,
                           stdout=subprocess.PIPE,

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/21/2020 11:48 AM, Jon Turney wrote:
> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>
>>
>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>>> I would like to adopt gimp and related packages.  At the moment I'm having 
>>>>> trouble with babl, which is needed for gegl0.4, which is needed for gimp. 
>>>>> The problem involves gobject-introspection.
>>>>>
>>>>> If I disable introspection, the build works fine.  This would be OK, since 
>>>>> babl has been built without introspection for several years. But then the 
>>>>> gegl0.4 build complains about the missing babl introspection files, so I 
>>>>> would have to disable introspection there too, which hasn't been done in 
>>>>> the past.
>>>>>
>>>>> So my preference is to figure out what the problem is and get the babl 
>>>>> build working with introspection.  I'm attaching my cygport file and patch.
>>>>>
>>>>> Here's the failing command...
>>>>>
>>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>>> -DBABL_IS_BEING_COMPILED 
>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>>> --cflags-begin -fno-unsafe-math-optimizations -Wdeclaration-after-statement 
>>>>> -Winit-self -Wmissing-declarations -Wmissing-prototypes 
>>>>> -Wold-style-definition -Wpointer-arith -mmmx -msse -mfpmath=sse -I./. 
>>>>> -I../. -I./babl/base/. -I../babl/base/. --cflags-end --library babl-0.1 
>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>>>
>>>>> ...and the error message:
>>>>>
>>>>> g-ir-scanner: link: gcc -o 
>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>>>> -fstack-protector-strong --param=ssp-buffer-size=4 
>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 
>>>>> -lintl
>>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>>
>>>>> I don't understand the error message, because the command line contains
>>>>>
>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>>>>
>>>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I even 
>>>>> tried adding that directory to my PATH to make sure the right 
>>>>> cygbabl-0.1-0.dll would be found, but that didn't help.
>>>
>>> This might possibly be related to the problem described in the comment for:
>>>
>>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
>>>
>>>
>>>> By the way, in case you're wondering why I disabled the building of docs, 
>>>> it's because I was getting a build failure there too.  I don't know if this 
>>>> is related to the introspection failure.  The failing command there is
>>>>
>>>> /usr/bin/meson --internal exe --unpickle 
>>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>>
>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>
>>>> I don't know why it's not showing me the actual cp command that fails. 
>>>
>>> I believe it's is an infelicity in meson that it doesn't echo the actual 
>>> failing command here.
>>>
>>> Noted here: https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>>
>>>> The corresponding information in docs/meson.build is
>>>>
>>>> Reference_html = custom_target('Reference.html',
>>>>    input : [
>>>>      'Reference-static.html',
>>>>      'toc',
>>>>      index_html_tmp,
>>>>    ],
>>>>    output: [ 'Reference.html', ],
>>>>    command: [
>>>>      env_bin,
>>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>>    ],
>>>>    build_by_default: true,
>>>> )
>>>>
>>>> There are several such custom targets in the file, and for all except this 
>>>> one, I see the actual cp command in the log.  This is the only one for which 
>>>> meson generates a 'meson --unpickle' command instead of a cp command.
>>>
>>> Yeah, I wasn't expecting it to use this method of executing the command line 
>>> (storing it in a pickle and then using a python wrapper to execute it) to be 
>>> used except on Windows, so I'll have to take a more detailed look at why 
>>> that's happening.
>>
>> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
>>
>>    /usr/bin/env \
>>       cp ../docs/Reference-static.html docs/Reference.html \
>>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
>>        && ../docs/tools/xml_insert.sh \
>>           docs/Reference.html BablBase docs/index.html.tmp
>>
>> This succeeds when run manually in the build directory.  So something must 
>> have gone wrong in the pickling/unpickling process.
> 
> 
> patching /usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
> something like this might shed some light:
> 
> --- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
> +++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
> @@ -57,6 +57,8 @@
>                   ['Z:' + p for p in exe.extra_paths] + 
> child_env.get('WINEPATH', '').split(';')
>               )
> 
> +    print(cmd_args)
> +
>       p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
>                            close_fds=False,
>                            stdout=subprocess.PIPE,

OK, now the log shows

cp: target 'docs/index.html.tmp' is not a directory
['/usr/bin/env', 'cp', '../docs/Reference-static.html', 'docs/Reference.html', 
'&&', 
'/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
'docs/Reference.html', 'TOC', '../docs/toc', '&&', 
'/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
'docs/Reference.html', 'BablBase', 'docs/index.html.tmp']

This does indeed shed some light.  If I remove all the commas but leave the 
single quotes, the command fails with the same error message as before:

cp: target 'docs/index.html.tmp' is not a directory

If I also remove the single quotes, the command succeeds.  I think the problem 
is the quotes around the double ampersands, so they are treated as arguments to 
the cp command instead of being interpreted by the shell executing the command.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
> On 5/21/2020 11:48 AM, Jon Turney wrote:
>> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>>>> I would like to adopt gimp and related packages.  At the moment 
>>>>>> I'm having trouble with babl, which is needed for gegl0.4, which 
>>>>>> is needed for gimp. The problem involves gobject-introspection.
>>>>>>
>>>>>> If I disable introspection, the build works fine.  This would be 
>>>>>> OK, since babl has been built without introspection for several 
>>>>>> years. But then the gegl0.4 build complains about the missing babl 
>>>>>> introspection files, so I would have to disable introspection 
>>>>>> there too, which hasn't been done in the past.
>>>>>>
>>>>>> So my preference is to figure out what the problem is and get the 
>>>>>> babl build working with introspection.  I'm attaching my cygport 
>>>>>> file and patch.
>>>>>>
>>>>>> Here's the failing command...
>>>>>>
>>>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>>>> -DBABL_IS_BEING_COMPILED 
>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>>>> --cflags-begin -fno-unsafe-math-optimizations 
>>>>>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>>>>>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx 
>>>>>> -msse -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>>>> --cflags-end --library babl-0.1 
>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>>>>
>>>>>> ...and the error message:
>>>>>>
>>>>>> g-ir-scanner: link: gcc -o 
>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>>>> -ggdb -O2 -pipe -Wall -Werror=format-security 
>>>>>> -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong 
>>>>>> --param=ssp-buffer-size=4 
>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
>>>>>> -lglib-2.0 -lintl
>>>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>>>
>>>>>> I don't understand the error message, because the command line 
>>>>>> contains
>>>>>>
>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>
>>>>>>
>>>>>> and that directory contains libbabl-0.1.dll.a and 
>>>>>> cygbabl-0.1-0.dll. I even tried adding that directory to my PATH 
>>>>>> to make sure the right cygbabl-0.1-0.dll would be found, but that 
>>>>>> didn't help.
>>>>
>>>> This might possibly be related to the problem described in the 
>>>> comment for:
>>>>
>>>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 

Yeah, this looks extremely plausible, there seem to be no GObject 
derived types in babl's interface.

It might be possible to work around this by patching in a dummy GObject 
derived type which does nothing.

I'll have to see if I can find my notes about how I debugged this before.

>>>>> By the way, in case you're wondering why I disabled the building of 
>>>>> docs, it's because I was getting a build failure there too.  I 
>>>>> don't know if this is related to the introspection failure.  The 
>>>>> failing command there is
>>>>>
>>>>> /usr/bin/meson --internal exe --unpickle 
>>>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>>>
>>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>>
>>>>> I don't know why it's not showing me the actual cp command that fails. 
>>>>
>>>> I believe it's is an infelicity in meson that it doesn't echo the 
>>>> actual failing command here.
>>>>
>>>> Noted here: 
>>>> https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>>>
>>>>> The corresponding information in docs/meson.build is
>>>>>
>>>>> Reference_html = custom_target('Reference.html',
>>>>>    input : [
>>>>>      'Reference-static.html',
>>>>>      'toc',
>>>>>      index_html_tmp,
>>>>>    ],
>>>>>    output: [ 'Reference.html', ],
>>>>>    command: [
>>>>>      env_bin,
>>>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>>>    ],
>>>>>    build_by_default: true,
>>>>> )
>>>>>
>>>>> There are several such custom targets in the file, and for all 
>>>>> except this one, I see the actual cp command in the log.  This is 
>>>>> the only one for which meson generates a 'meson --unpickle' command 
>>>>> instead of a cp command.
>>>>
>>>> Yeah, I wasn't expecting it to use this method of executing the 
>>>> command line (storing it in a pickle and then using a python wrapper 
>>>> to execute it) to be used except on Windows, so I'll have to take a 
>>>> more detailed look at why that's happening.

So, it's correct that it runs this command indirectly via the pickle, 
because it needs to interpose itself to do some PATH manipulation to add 
the DLL, because this target has the 'babl-html-dump' tool, which is 
linked with the DLL, in it's input (indirectly).

>>> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
>>>
>>>    /usr/bin/env \
>>>       cp ../docs/Reference-static.html docs/Reference.html \
>>>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC 
>>> ../docs/toc \
>>>        && ../docs/tools/xml_insert.sh \
>>>           docs/Reference.html BablBase docs/index.html.tmp
>>>
>>> This succeeds when run manually in the build directory.  So something 
>>> must have gone wrong in the pickling/unpickling process.
>>
>>
>> patching 
>> /usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
>> something like this might shed some light:
>>
>> --- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
>> +++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
>> @@ -57,6 +57,8 @@
>>                   ['Z:' + p for p in exe.extra_paths] + 
>> child_env.get('WINEPATH', '').split(';')
>>               )
>>
>> +    print(cmd_args)
>> +
>>       p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
>>                            close_fds=False,
>>                            stdout=subprocess.PIPE,
> 
> OK, now the log shows
> 
> cp: target 'docs/index.html.tmp' is not a directory
> ['/usr/bin/env', 'cp', '../docs/Reference-static.html', 
> 'docs/Reference.html', '&&', 
> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
> 'docs/Reference.html', 'TOC', '../docs/toc', '&&', 
> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
> 'docs/Reference.html', 'BablBase', 'docs/index.html.tmp']
> 
> This does indeed shed some light.  If I remove all the commas but leave 
> the single quotes, the command fails with the same error message as before:
> 
> cp: target 'docs/index.html.tmp' is not a directory
> 
> If I also remove the single quotes, the command succeeds.  I think the 
> problem is the quotes around the double ampersands, so they are treated 
> as arguments to the cp command instead of being interpreted by the shell 
> executing the command.

So, yeah, this is a meson bug, which I will work on (if this command 
ends up in the build.ninja, it's executed by ninja with 'sh -c', but if 
it ends up in a pickle, it's executed by meson with execve())

(Ofc, everything behaves differently if we are building on Windows, and 
CreateProcess() is used in both places, so allowing shell control 
operators here is not very portable)

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/24/2020 11:56 AM, Jon Turney wrote:
> On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
>> On 5/21/2020 11:48 AM, Jon Turney wrote:
>>> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>>>>> I would like to adopt gimp and related packages.  At the moment I'm 
>>>>>>> having trouble with babl, which is needed for gegl0.4, which is needed 
>>>>>>> for gimp. The problem involves gobject-introspection.
>>>>>>>
>>>>>>> If I disable introspection, the build works fine.  This would be OK, 
>>>>>>> since babl has been built without introspection for several years. But 
>>>>>>> then the gegl0.4 build complains about the missing babl introspection 
>>>>>>> files, so I would have to disable introspection there too, which hasn't 
>>>>>>> been done in the past.
>>>>>>>
>>>>>>> So my preference is to figure out what the problem is and get the babl 
>>>>>>> build working with introspection.  I'm attaching my cygport file and patch.
>>>>>>>
>>>>>>> Here's the failing command...
>>>>>>>
>>>>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>>>>> -DBABL_IS_BEING_COMPILED 
>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>>>>> --cflags-begin -fno-unsafe-math-optimizations 
>>>>>>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>>>>>>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse 
>>>>>>> -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end 
>>>>>>> --library babl-0.1 
>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>>>>>
>>>>>>> ...and the error message:
>>>>>>>
>>>>>>> g-ir-scanner: link: gcc -o 
>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>>>>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>>>>>> -fstack-protector-strong --param=ssp-buffer-size=4 
>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 
>>>>>>> -lintl
>>>>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>>>>
>>>>>>> I don't understand the error message, because the command line contains
>>>>>>>
>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>>>>>>
>>>>>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I 
>>>>>>> even tried adding that directory to my PATH to make sure the right 
>>>>>>> cygbabl-0.1-0.dll would be found, but that didn't help.
>>>>>
>>>>> This might possibly be related to the problem described in the comment for:
>>>>>
>>>>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
> 
> 
> Yeah, this looks extremely plausible, there seem to be no GObject derived types 
> in babl's interface.
> 
> It might be possible to work around this by patching in a dummy GObject derived 
> type which does nothing.
> 
> I'll have to see if I can find my notes about how I debugged this before.
> 
>>>>>> By the way, in case you're wondering why I disabled the building of docs, 
>>>>>> it's because I was getting a build failure there too.  I don't know if 
>>>>>> this is related to the introspection failure.  The failing command there is
>>>>>>
>>>>>> /usr/bin/meson --internal exe --unpickle 
>>>>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>>>>
>>>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>>>
>>>>>> I don't know why it's not showing me the actual cp command that fails. 
>>>>>
>>>>> I believe it's is an infelicity in meson that it doesn't echo the actual 
>>>>> failing command here.
>>>>>
>>>>> Noted here: 
>>>>> https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>>>>
>>>>>> The corresponding information in docs/meson.build is
>>>>>>
>>>>>> Reference_html = custom_target('Reference.html',
>>>>>>    input : [
>>>>>>      'Reference-static.html',
>>>>>>      'toc',
>>>>>>      index_html_tmp,
>>>>>>    ],
>>>>>>    output: [ 'Reference.html', ],
>>>>>>    command: [
>>>>>>      env_bin,
>>>>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>>>>    ],
>>>>>>    build_by_default: true,
>>>>>> )
>>>>>>
>>>>>> There are several such custom targets in the file, and for all except this 
>>>>>> one, I see the actual cp command in the log.  This is the only one for 
>>>>>> which meson generates a 'meson --unpickle' command instead of a cp command.
>>>>>
>>>>> Yeah, I wasn't expecting it to use this method of executing the command 
>>>>> line (storing it in a pickle and then using a python wrapper to execute it) 
>>>>> to be used except on Windows, so I'll have to take a more detailed look at 
>>>>> why that's happening.
> 
> So, it's correct that it runs this command indirectly via the pickle, because it 
> needs to interpose itself to do some PATH manipulation to add the DLL, because 
> this target has the 'babl-html-dump' tool, which is linked with the DLL, in it's 
> input (indirectly).
> 
>>>> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
>>>>
>>>>    /usr/bin/env \
>>>>       cp ../docs/Reference-static.html docs/Reference.html \
>>>>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
>>>>        && ../docs/tools/xml_insert.sh \
>>>>           docs/Reference.html BablBase docs/index.html.tmp
>>>>
>>>> This succeeds when run manually in the build directory.  So something must 
>>>> have gone wrong in the pickling/unpickling process.
>>>
>>>
>>> patching /usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
>>> something like this might shed some light:
>>>
>>> --- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
>>> +++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
>>> @@ -57,6 +57,8 @@
>>>                   ['Z:' + p for p in exe.extra_paths] + 
>>> child_env.get('WINEPATH', '').split(';')
>>>               )
>>>
>>> +    print(cmd_args)
>>> +
>>>       p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
>>>                            close_fds=False,
>>>                            stdout=subprocess.PIPE,
>>
>> OK, now the log shows
>>
>> cp: target 'docs/index.html.tmp' is not a directory
>> ['/usr/bin/env', 'cp', '../docs/Reference-static.html', 'docs/Reference.html', 
>> '&&', 
>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>> 'docs/Reference.html', 'TOC', '../docs/toc', '&&', 
>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>> 'docs/Reference.html', 'BablBase', 'docs/index.html.tmp']
>>
>> This does indeed shed some light.  If I remove all the commas but leave the 
>> single quotes, the command fails with the same error message as before:
>>
>> cp: target 'docs/index.html.tmp' is not a directory
>>
>> If I also remove the single quotes, the command succeeds.  I think the problem 
>> is the quotes around the double ampersands, so they are treated as arguments 
>> to the cp command instead of being interpreted by the shell executing the 
>> command.
> 
> So, yeah, this is a meson bug, which I will work on (if this command ends up in 
> the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a 
> pickle, it's executed by meson with execve())

Yes, that does seem like a meson bug.  But is it also a babl bug to some extent? 
  When babl puts '&&' in a command argument, it's assuming that the command will 
be executed by 'sh -c'.

I have very little experience with meson.  Have you ever seen this issue in 
other projects that use meson?

> (Ofc, everything behaves differently if we are building on Windows, and 
> CreateProcess() is used in both places, so allowing shell control operators here 
> is not very portable)

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote:
> On 5/24/2020 11:56 AM, Jon Turney wrote:
>> On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
>>> On 5/21/2020 11:48 AM, Jon Turney wrote:
>>>> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>>>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>>>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>>>>>> I would like to adopt gimp and related packages.  At the moment I'm 
>>>>>>>> having trouble with babl, which is needed for gegl0.4, which is needed 
>>>>>>>> for gimp. The problem involves gobject-introspection.
>>>>>>>>
>>>>>>>> If I disable introspection, the build works fine.  This would be OK, 
>>>>>>>> since babl has been built without introspection for several years. But 
>>>>>>>> then the gegl0.4 build complains about the missing babl introspection 
>>>>>>>> files, so I would have to disable introspection there too, which hasn't 
>>>>>>>> been done in the past.
>>>>>>>>
>>>>>>>> So my preference is to figure out what the problem is and get the babl 
>>>>>>>> build working with introspection.  I'm attaching my cygport file and patch.
>>>>>>>>
>>>>>>>> Here's the failing command...
>>>>>>>>
>>>>>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>>>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>>>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>>>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>>>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>>>>>> -DBABL_IS_BEING_COMPILED 
>>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -I./. 
>>>>>>>> -I../. -I./babl/base/. -I../babl/base/. 
>>>>>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>>>>>> --cflags-begin -fno-unsafe-math-optimizations 
>>>>>>>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>>>>>>>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse 
>>>>>>>> -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end 
>>>>>>>> --library babl-0.1 
>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl --extra-library=m 
>>>>>>>> --extra-library=dl --extra-library=lcms2
>>>>>>>>
>>>>>>>> ...and the error message:
>>>>>>>>
>>>>>>>> g-ir-scanner: link: gcc -o 
>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>>>>>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>>>>>>> -fstack-protector-strong --param=ssp-buffer-size=4 
>>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>>>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
>>>>>>>> -lglib-2.0 -lintl
>>>>>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>>>>>
>>>>>>>> I don't understand the error message, because the command line contains
>>>>>>>>
>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>>>>>>>
>>>>>>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I 
>>>>>>>> even tried adding that directory to my PATH to make sure the right 
>>>>>>>> cygbabl-0.1-0.dll would be found, but that didn't help.
>>>>>>
>>>>>> This might possibly be related to the problem described in the comment for:
>>>>>>
>>>>>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
>>
>>
>>
>> Yeah, this looks extremely plausible, there seem to be no GObject derived 
>> types in babl's interface.
>>
>> It might be possible to work around this by patching in a dummy GObject 
>> derived type which does nothing.
>>
>> I'll have to see if I can find my notes about how I debugged this before.
>>
>>>>>>> By the way, in case you're wondering why I disabled the building of docs, 
>>>>>>> it's because I was getting a build failure there too.  I don't know if 
>>>>>>> this is related to the introspection failure.  The failing command there is
>>>>>>>
>>>>>>> /usr/bin/meson --internal exe --unpickle 
>>>>>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>>>>>
>>>>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>>>>
>>>>>>> I don't know why it's not showing me the actual cp command that fails. 
>>>>>>
>>>>>> I believe it's is an infelicity in meson that it doesn't echo the actual 
>>>>>> failing command here.
>>>>>>
>>>>>> Noted here: 
>>>>>> https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>>>>>
>>>>>>> The corresponding information in docs/meson.build is
>>>>>>>
>>>>>>> Reference_html = custom_target('Reference.html',
>>>>>>>    input : [
>>>>>>>      'Reference-static.html',
>>>>>>>      'toc',
>>>>>>>      index_html_tmp,
>>>>>>>    ],
>>>>>>>    output: [ 'Reference.html', ],
>>>>>>>    command: [
>>>>>>>      env_bin,
>>>>>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>>>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>>>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>>>>>    ],
>>>>>>>    build_by_default: true,
>>>>>>> )
>>>>>>>
>>>>>>> There are several such custom targets in the file, and for all except 
>>>>>>> this one, I see the actual cp command in the log.  This is the only one 
>>>>>>> for which meson generates a 'meson --unpickle' command instead of a cp 
>>>>>>> command.
>>>>>>
>>>>>> Yeah, I wasn't expecting it to use this method of executing the command 
>>>>>> line (storing it in a pickle and then using a python wrapper to execute 
>>>>>> it) to be used except on Windows, so I'll have to take a more detailed 
>>>>>> look at why that's happening.
>>
>> So, it's correct that it runs this command indirectly via the pickle, because 
>> it needs to interpose itself to do some PATH manipulation to add the DLL, 
>> because this target has the 'babl-html-dump' tool, which is linked with the 
>> DLL, in it's input (indirectly).
>>
>>>>> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
>>>>>
>>>>>    /usr/bin/env \
>>>>>       cp ../docs/Reference-static.html docs/Reference.html \
>>>>>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
>>>>>        && ../docs/tools/xml_insert.sh \
>>>>>           docs/Reference.html BablBase docs/index.html.tmp
>>>>>
>>>>> This succeeds when run manually in the build directory.  So something must 
>>>>> have gone wrong in the pickling/unpickling process.
>>>>
>>>>
>>>> patching /usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
>>>> something like this might shed some light:
>>>>
>>>> --- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
>>>> +++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
>>>> @@ -57,6 +57,8 @@
>>>>                   ['Z:' + p for p in exe.extra_paths] + 
>>>> child_env.get('WINEPATH', '').split(';')
>>>>               )
>>>>
>>>> +    print(cmd_args)
>>>> +
>>>>       p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
>>>>                            close_fds=False,
>>>>                            stdout=subprocess.PIPE,
>>>
>>> OK, now the log shows
>>>
>>> cp: target 'docs/index.html.tmp' is not a directory
>>> ['/usr/bin/env', 'cp', '../docs/Reference-static.html', 
>>> 'docs/Reference.html', '&&', 
>>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>>> 'docs/Reference.html', 'TOC', '../docs/toc', '&&', 
>>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>>> 'docs/Reference.html', 'BablBase', 'docs/index.html.tmp']
>>>
>>> This does indeed shed some light.  If I remove all the commas but leave the 
>>> single quotes, the command fails with the same error message as before:
>>>
>>> cp: target 'docs/index.html.tmp' is not a directory
>>>
>>> If I also remove the single quotes, the command succeeds.  I think the 
>>> problem is the quotes around the double ampersands, so they are treated as 
>>> arguments to the cp command instead of being interpreted by the shell 
>>> executing the command.
>>
>> So, yeah, this is a meson bug, which I will work on (if this command ends up 
>> in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in 
>> a pickle, it's executed by meson with execve())
> 
> Yes, that does seem like a meson bug.  But is it also a babl bug to some extent? 
>   When babl puts '&&' in a command argument, it's assuming that the command will 
> be executed by 'sh -c'.
> 
> I have very little experience with meson.  Have you ever seen this issue in 
> other projects that use meson?

I just noticed this, at https://mesonbuild.com/Custom-build-targets.html :

   Meson only permits you to specify one command to run. This is
   by design as writing shell pipelines into build definition
   files leads to code that is very hard to maintain. If your
   compilation requires multiple steps you need to write a wrapper
   script that does all the necessary work.

We're not talking about a shell pipeline here, but it's similar.  So I'm 
thinking this really is a babl bug.

Ken

Re: Help needed with gobject-introspection

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 10307 bytes --]

On 5/24/2020 1:00 PM, Ken Brown via Cygwin-apps wrote:
> On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote:
>> On 5/24/2020 11:56 AM, Jon Turney wrote:
>>> On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
>>>> On 5/21/2020 11:48 AM, Jon Turney wrote:
>>>>> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>>>>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>>>>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>>>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
>>>>>>>>> I would like to adopt gimp and related packages.  At the moment I'm 
>>>>>>>>> having trouble with babl, which is needed for gegl0.4, which is needed 
>>>>>>>>> for gimp. The problem involves gobject-introspection.
>>>>>>>>>
>>>>>>>>> If I disable introspection, the build works fine.  This would be OK, 
>>>>>>>>> since babl has been built without introspection for several years. But 
>>>>>>>>> then the gegl0.4 build complains about the missing babl introspection 
>>>>>>>>> files, so I would have to disable introspection there too, which hasn't 
>>>>>>>>> been done in the past.
>>>>>>>>>
>>>>>>>>> So my preference is to figure out what the problem is and get the babl 
>>>>>>>>> build working with introspection.  I'm attaching my cygport file and 
>>>>>>>>> patch.
>>>>>>>>>
>>>>>>>>> Here's the failing command...
>>>>>>>>>
>>>>>>>>> /usr/bin/g-ir-scanner -I/usr/include/gobject-introspection-1.0 
>>>>>>>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT 
>>>>>>>>> --no-libtool --namespace=Babl --nsversion=0.1 --warn-all --output 
>>>>>>>>> babl/Babl-0.1.gir --c-include=babl.h 
>>>>>>>>> '--identifier-filter-cmd=/usr/bin/python3 
>>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl/identfilter.py' 
>>>>>>>>> -DBABL_IS_BEING_COMPILED 
>>>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/babl 
>>>>>>>>> -I/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>>>> -I./. -I../. -I./babl/base/. -I../babl/base/. 
>>>>>>>>> --filelist=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl/4170c83@@babl-0.1@sha/Babl_0.1_gir_filelist 
>>>>>>>>> --cflags-begin -fno-unsafe-math-optimizations 
>>>>>>>>> -Wdeclaration-after-statement -Winit-self -Wmissing-declarations 
>>>>>>>>> -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -mmmx -msse 
>>>>>>>>> -mfpmath=sse -I./. -I../. -I./babl/base/. -I../babl/base/. --cflags-end 
>>>>>>>>> --library babl-0.1 
>>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>>>> --extra-library=m --extra-library=dl --extra-library=lcms2
>>>>>>>>>
>>>>>>>>> ...and the error message:
>>>>>>>>>
>>>>>>>>> g-ir-scanner: link: gcc -o 
>>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.exe 
>>>>>>>>> -ggdb -O2 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>>>>>>>> -fstack-protector-strong --param=ssp-buffer-size=4 
>>>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/build=/usr/src/debug/babl-0.1.74-1 
>>>>>>>>> -fdebug-prefix-map=/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74=/usr/src/debug/babl-0.1.74-1 
>>>>>>>>> /tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/tmp-introspectCwCaUc/Babl-0.1.o 
>>>>>>>>> -L. -lbabl-0.1 -lm -ldl -llcms2 
>>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>>>> -Wl,-rpath,/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl 
>>>>>>>>> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
>>>>>>>>> -lglib-2.0 -lintl
>>>>>>>>> ERROR: can't resolve libraries to shared libraries: babl-0.1
>>>>>>>>>
>>>>>>>>> I don't understand the error message, because the command line contains
>>>>>>>>>
>>>>>>>>> -L/tmp/cygbabl/babl-0.1.74-1.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/babl
>>>>>>>>>
>>>>>>>>> and that directory contains libbabl-0.1.dll.a and cygbabl-0.1-0.dll. I 
>>>>>>>>> even tried adding that directory to my PATH to make sure the right 
>>>>>>>>> cygbabl-0.1-0.dll would be found, but that didn't help.
>>>>>>>
>>>>>>> This might possibly be related to the problem described in the comment for:
>>>>>>>
>>>>>>> https://github.com/mesonbuild/meson/pull/2880/commits/8a27c08b05e4537d5061d30ddd8aad9dc52cf1c4 
>>>
>>>
>>>
>>>
>>> Yeah, this looks extremely plausible, there seem to be no GObject derived 
>>> types in babl's interface.
>>>
>>> It might be possible to work around this by patching in a dummy GObject 
>>> derived type which does nothing.
>>>
>>> I'll have to see if I can find my notes about how I debugged this before.
>>>
>>>>>>>> By the way, in case you're wondering why I disabled the building of 
>>>>>>>> docs, it's because I was getting a build failure there too.  I don't 
>>>>>>>> know if this is related to the introspection failure.  The failing 
>>>>>>>> command there is
>>>>>>>>
>>>>>>>> /usr/bin/meson --internal exe --unpickle 
>>>>>>>> /tmp/cygbabl/babl-0.1.74-2.x86_64/src/babl-0.1.74/x86_64-pc-cygwin/meson-private/meson_exe_env_7bf39b99114d34540b83d26a5d8f097e05882836.dat 
>>>>>>>>
>>>>>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>>>>>
>>>>>>>> I don't know why it's not showing me the actual cp command that fails. 
>>>>>>>
>>>>>>> I believe it's is an infelicity in meson that it doesn't echo the actual 
>>>>>>> failing command here.
>>>>>>>
>>>>>>> Noted here: 
>>>>>>> https://github.com/mesonbuild/meson/pull/3716#issuecomment-395746838
>>>>>>>
>>>>>>>> The corresponding information in docs/meson.build is
>>>>>>>>
>>>>>>>> Reference_html = custom_target('Reference.html',
>>>>>>>>    input : [
>>>>>>>>      'Reference-static.html',
>>>>>>>>      'toc',
>>>>>>>>      index_html_tmp,
>>>>>>>>    ],
>>>>>>>>    output: [ 'Reference.html', ],
>>>>>>>>    command: [
>>>>>>>>      env_bin,
>>>>>>>>      'cp', '@INPUT0@', '@OUTPUT@',
>>>>>>>>      '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
>>>>>>>>      '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
>>>>>>>>    ],
>>>>>>>>    build_by_default: true,
>>>>>>>> )
>>>>>>>>
>>>>>>>> There are several such custom targets in the file, and for all except 
>>>>>>>> this one, I see the actual cp command in the log.  This is the only one 
>>>>>>>> for which meson generates a 'meson --unpickle' command instead of a cp 
>>>>>>>> command.
>>>>>>>
>>>>>>> Yeah, I wasn't expecting it to use this method of executing the command 
>>>>>>> line (storing it in a pickle and then using a python wrapper to execute 
>>>>>>> it) to be used except on Windows, so I'll have to take a more detailed 
>>>>>>> look at why that's happening.
>>>
>>> So, it's correct that it runs this command indirectly via the pickle, because 
>>> it needs to interpose itself to do some PATH manipulation to add the DLL, 
>>> because this target has the 'babl-html-dump' tool, which is linked with the 
>>> DLL, in it's input (indirectly).
>>>
>>>>>> Thanks.  FWIW, the recipe for building docs/Reference.html translates to
>>>>>>
>>>>>>    /usr/bin/env \
>>>>>>       cp ../docs/Reference-static.html docs/Reference.html \
>>>>>>        && ../docs/tools/xml_insert.sh docs/Reference.html TOC ../docs/toc \
>>>>>>        && ../docs/tools/xml_insert.sh \
>>>>>>           docs/Reference.html BablBase docs/index.html.tmp
>>>>>>
>>>>>> This succeeds when run manually in the build directory.  So something must 
>>>>>> have gone wrong in the pickling/unpickling process.
>>>>>
>>>>>
>>>>> patching /usr/lib/python3.6/site-packages/mesonbuild/scripts/meson_exe.py 
>>>>> something like this might shed some light:
>>>>>
>>>>> --- meson_exe.py.bak    2020-05-21 15:01:19.187046500 +0100
>>>>> +++ meson_exe.py        2020-05-21 15:09:29.485915300 +0100
>>>>> @@ -57,6 +57,8 @@
>>>>>                   ['Z:' + p for p in exe.extra_paths] + 
>>>>> child_env.get('WINEPATH', '').split(';')
>>>>>               )
>>>>>
>>>>> +    print(cmd_args)
>>>>> +
>>>>>       p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
>>>>>                            close_fds=False,
>>>>>                            stdout=subprocess.PIPE,
>>>>
>>>> OK, now the log shows
>>>>
>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>> ['/usr/bin/env', 'cp', '../docs/Reference-static.html', 
>>>> 'docs/Reference.html', '&&', 
>>>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>>>> 'docs/Reference.html', 'TOC', '../docs/toc', '&&', 
>>>> '/home/kbrown/src/cygpackages/babl/babl-0.1.74-1.x86_64/src/babl-0.1.74/docs/tools/xml_insert.sh', 
>>>> 'docs/Reference.html', 'BablBase', 'docs/index.html.tmp']
>>>>
>>>> This does indeed shed some light.  If I remove all the commas but leave the 
>>>> single quotes, the command fails with the same error message as before:
>>>>
>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>
>>>> If I also remove the single quotes, the command succeeds.  I think the 
>>>> problem is the quotes around the double ampersands, so they are treated as 
>>>> arguments to the cp command instead of being interpreted by the shell 
>>>> executing the command.
>>>
>>> So, yeah, this is a meson bug, which I will work on (if this command ends up 
>>> in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in 
>>> a pickle, it's executed by meson with execve())
>>
>> Yes, that does seem like a meson bug.  But is it also a babl bug to some 
>> extent?   When babl puts '&&' in a command argument, it's assuming that the 
>> command will be executed by 'sh -c'.
>>
>> I have very little experience with meson.  Have you ever seen this issue in 
>> other projects that use meson?
> 
> I just noticed this, at https://mesonbuild.com/Custom-build-targets.html :
> 
>    Meson only permits you to specify one command to run. This is
>    by design as writing shell pipelines into build definition
>    files leads to code that is very hard to maintain. If your
>    compilation requires multiple steps you need to write a wrapper
>    script that does all the necessary work.
> 
> We're not talking about a shell pipeline here, but it's similar.  So I'm 
> thinking this really is a babl bug.

Regardless of whose bug it is, I've got a simple but ugly workaround (attached), 
now that you've explained to me what's going on.

Ken

[-- Attachment #2: 0.1.74-docs.patch --]
[-- Type: text/plain, Size: 1588 bytes --]

--- origsrc/babl-0.1.74/docs/meson.build	2020-01-12 18:26:51.000000000 -0500
+++ src/babl-0.1.74/docs/meson.build	2020-05-24 22:10:24.081359400 -0400
@@ -54,22 +54,26 @@ index_html = custom_target('index.html',
   build_by_default: true,
 )
 
-Reference_html = custom_target('Reference.html',
+Reference_html_tmp = custom_target('Reference.html.tmp',
   input : [
     'Reference-static.html',
     'toc',
-    index_html_tmp,
   ],
-  output: [ 'Reference.html', ],
+  output: [ 'Reference.html.tmp', ],
   command: [
     env_bin,
     'cp', '@INPUT0@', '@OUTPUT@',
     '&&', xml_insert, '@OUTPUT@', 'TOC', '@INPUT1@',
-    '&&', xml_insert, '@OUTPUT@', 'BablBase', '@INPUT2@',
   ],
-  build_by_default: true,
 )
 
+Reference_html = custom_target('Reference.html',
+  input : [ Reference_html_tmp, index_html_tmp, ],
+  output: [ 'Reference.html', ],
+  command: [ xml_insert, '@INPUT0@', 'BablBase', '@INPUT1@', 'cat_result' ],
+  build_by_default: true,
+  capture: true,
+)
 
 CMYK_html = custom_target('CMYK.html',
   input : [
--- origsrc/babl-0.1.74/docs/tools/xml_insert.sh	2020-01-12 18:26:51.000000000 -0500
+++ src/babl-0.1.74/docs/tools/xml_insert.sh	2020-05-25 07:54:31.875472500 -0400
@@ -7,6 +7,9 @@
 #
 # xml_insert.sh bar.xml foo foo.inc
 #
+# If there's a fourth argument, cat the final result.
+#
+#
 # 2005 © Øyvind Kolås
 #
 # FIXME: add argument checking / error handling
@@ -97,6 +100,9 @@ tailno=`expr $numlines - $splitno`
 head -$splitno $tmp_file > $1
 cat $3 >> $1
 tail -$tailno $tmp_file >> $1
+if test -n "$4"; then
+  cat $1
+fi
 
 rm -rf $tmp_dir
 

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/24/2020 11:56 AM, Jon Turney wrote:
> So, yeah, this is a meson bug, which I will work on (if this command ends up in 
> the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a 
> pickle, it's executed by meson with execve())

It looks like I've bumped into a variation of this bug.  While attempting to 
build the documentation for the latest glib2.0 release, I got the following:

FAILED: docs/reference/gobject/gobject-decl.txt
/usr/bin/meson --internal exe --unpickle 
/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat
['/usr/bin/meson', '--internal', 'gtkdoc', 
'--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', 
'--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', 
'--subdir=docs/reference/gobject', '--headerdirs=gobject', 
'--mainfile=gobject-docs.xml', '--modulename=gobject', '--

[...]

/docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', 
'--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. -I../. 
-I@BUILD_ROOT@/glib -I../glib -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs

[...]

So @BUILD_ROOT@ didn't get replaced by the build root after pickling and 
unpickling.  Needless to say, this produced errors like:

cc1: error: @BUILD_ROOT@/glib: No such file or directory 
[-Werror=missing-include-dirs]

I can give you a precise recipe for reproducing this bug if it would help your 
debugging.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote:
> On 5/24/2020 11:56 AM, Jon Turney wrote:
>> So, yeah, this is a meson bug, which I will work on (if this command 
>> ends up in the build.ninja, it's executed by ninja with 'sh -c', but 
>> if it ends up in a pickle, it's executed by meson with execve())
> 
> It looks like I've bumped into a variation of this bug.  While 
> attempting to build the documentation for the latest glib2.0 release, I 
> got the following:
> 
> FAILED: docs/reference/gobject/gobject-decl.txt
> /usr/bin/meson --internal exe --unpickle 
> /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat 
> 
> ['/usr/bin/meson', '--internal', 'gtkdoc', 
> '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', 
> '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', 
> '--subdir=docs/reference/gobject', '--headerdirs=gobject', 
> '--mainfile=gobject-docs.xml', '--modulename=gobject', '--
> 
> [...]
> 
> /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', 
> '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. 
> -I../. -I@BUILD_ROOT@/glib -I../glib 
> -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs
> 
> [...]
> 
> So @BUILD_ROOT@ didn't get replaced by the build root after pickling and 
> unpickling.  Needless to say, this produced errors like:
> 
> cc1: error: @BUILD_ROOT@/glib: No such file or directory 
> [-Werror=missing-include-dirs]
> 
> I can give you a precise recipe for reproducing this bug if it would 
> help your debugging.

Definitely a bug.  I'll see if I can take a look at it this weekend.

Re: Help needed with gobject-introspection

[Jon Turney]

On 25/05/2020 16:04, Ken Brown via Cygwin-apps wrote:
> On 5/24/2020 1:00 PM, Ken Brown via Cygwin-apps wrote:
>> On 5/24/2020 12:45 PM, Ken Brown via Cygwin-apps wrote:
>>> On 5/24/2020 11:56 AM, Jon Turney wrote:
>>>> On 21/05/2020 18:07, Ken Brown via Cygwin-apps wrote:
>>>>> On 5/21/2020 11:48 AM, Jon Turney wrote:
>>>>>> On 21/05/2020 16:13, Ken Brown via Cygwin-apps wrote:
>>>>>>> On 5/21/2020 9:24 AM, Jon Turney wrote:
>>>>>>>> On 20/05/2020 15:50, Ken Brown via Cygwin-apps wrote:
>>>>>>>>> On 5/19/2020 7:04 PM, Ken Brown via Cygwin-apps wrote:
[...]
>>>>> This does indeed shed some light.  If I remove all the commas but 
>>>>> leave the single quotes, the command fails with the same error 
>>>>> message as before:
>>>>>
>>>>> cp: target 'docs/index.html.tmp' is not a directory
>>>>>
>>>>> If I also remove the single quotes, the command succeeds.  I think 
>>>>> the problem is the quotes around the double ampersands, so they are 
>>>>> treated as arguments to the cp command instead of being interpreted 
>>>>> by the shell executing the command.
>>>>
>>>> So, yeah, this is a meson bug, which I will work on (if this command 
>>>> ends up in the build.ninja, it's executed by ninja with 'sh -c', but 
>>>> if it ends up in a pickle, it's executed by meson with execve())
>>>
>>> Yes, that does seem like a meson bug.  But is it also a babl bug to 
>>> some extent?   When babl puts '&&' in a command argument, it's 
>>> assuming that the command will be executed by 'sh -c'.
>>>
>>> I have very little experience with meson.  Have you ever seen this 
>>> issue in other projects that use meson?
>>
>> I just noticed this, at 
>> https://mesonbuild.com/Custom-build-targets.html :
>>
>>    Meson only permits you to specify one command to run. This is
>>    by design as writing shell pipelines into build definition
>>    files leads to code that is very hard to maintain. If your
>>    compilation requires multiple steps you need to write a wrapper
>>    script that does all the necessary work.
>>
>> We're not talking about a shell pipeline here, but it's similar.  So 
>> I'm thinking this really is a babl bug.

Yeah. Ideally meson would stop people from writing custom targets which 
use shell operators.  Unfortunately, it doesn't and there are probably 
many other existing instances of this usage.

Additionally, meson is perhaps a bit schizophrenic on this topic and (I 
think) actually has code to make sure this works as expected when the 
command ends up being put directly into build.ninja (which is what will 
usually happen on linux etc.)

> Regardless of whose bug it is, I've got a simple but ugly workaround 
> (attached), now that you've explained to me what's going on.

Good stuff.

Re: Help needed with gobject-introspection

[Jon Turney]

On 29/05/2020 16:54, Jon Turney wrote:
> On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote:
>> It looks like I've bumped into a variation of this bug.  While 
>> attempting to build the documentation for the latest glib2.0 release, 
>> I got the following:
>>
>> FAILED: docs/reference/gobject/gobject-decl.txt
>> /usr/bin/meson --internal exe --unpickle 
>> /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat 
>>
>> ['/usr/bin/meson', '--internal', 'gtkdoc', 
>> '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', 
>> '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', 
>> '--subdir=docs/reference/gobject', '--headerdirs=gobject', 
>> '--mainfile=gobject-docs.xml', '--modulename=gobject', '--
>>
>> [...]
>>
>> /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', 
>> '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread 
>> -I@BUILD_ROOT@/. -I../. -I@BUILD_ROOT@/glib -I../glib 
>> -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs
>>
>> [...]
>>
>> So @BUILD_ROOT@ didn't get replaced by the build root after pickling 
>> and unpickling.  Needless to say, this produced errors like:
>>
>> cc1: error: @BUILD_ROOT@/glib: No such file or directory 
>> [-Werror=missing-include-dirs]
>>
>> I can give you a precise recipe for reproducing this bug if it would 
>> help your debugging.
> 
> Definitely a bug.  I'll see if I can take a look at it this weekend.

https://github.com/mesonbuild/meson/pull/7229

I made a meson 0.54.2-2 test package with those patches.

Re: Help needed with gobject-introspection

[Ken Brown]

On 5/31/2020 4:52 PM, Jon Turney wrote:
> On 29/05/2020 16:54, Jon Turney wrote:
>> On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote:
>>> It looks like I've bumped into a variation of this bug.  While attempting to 
>>> build the documentation for the latest glib2.0 release, I got the following:
>>>
>>> FAILED: docs/reference/gobject/gobject-decl.txt
>>> /usr/bin/meson --internal exe --unpickle 
>>> /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat 
>>>
>>> ['/usr/bin/meson', '--internal', 'gtkdoc', 
>>> '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', 
>>> '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', 
>>> '--subdir=docs/reference/gobject', '--headerdirs=gobject', 
>>> '--mainfile=gobject-docs.xml', '--modulename=gobject', '--
>>>
>>> [...]
>>>
>>> /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', 
>>> '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. 
>>> -I../. -I@BUILD_ROOT@/glib -I../glib -I@BUILD_ROOT@/docs/reference/gobject/. 
>>> -I../docs
>>>
>>> [...]
>>>
>>> So @BUILD_ROOT@ didn't get replaced by the build root after pickling and 
>>> unpickling.  Needless to say, this produced errors like:
>>>
>>> cc1: error: @BUILD_ROOT@/glib: No such file or directory 
>>> [-Werror=missing-include-dirs]
>>>
>>> I can give you a precise recipe for reproducing this bug if it would help 
>>> your debugging.
>>
>> Definitely a bug.  I'll see if I can take a look at it this weekend.
> 
> https://github.com/mesonbuild/meson/pull/7229
> 
> I made a meson 0.54.2-2 test package with those patches.

Thanks!  That gets me much further in the glib build.  I still have a problem 
with the docs, but I have no reason to think it's a meson bug.  When running 
'ninja install' I get the following:

Building documentation for gio
ERROR: Error in gtkdoc helper script:

ERROR: ['/usr/bin/gtkdoc-scangobj', 
'--types=/home/kbrown/src/glib/cygbuild/docs/reference/gio/gio.types', 
'--module=gio', '--run=', '--cflags=-I/home/kbrown/src/glib/cygbuild/gio 
-I/home/kbrown/src/glib/gio -pthread -I/home/kbrown/src/glib/cygbuild/gmodule 
-I/home/kbrown/src/glib/gmodule -I/home/kbrown/src/glib/cygbuild/. 
-I/home/kbrown/src/glib/. -I/home/kbrown/src/glib/cygbuild/glib 
-I/home/kbrown/src/glib/glib -I/home/kbrown/src/glib/cygbuild/gobject 
-I/home/kbrown/src/glib/gobject -D_GNU_SOURCE -fno-strict-aliasing 
-DG_ENABLE_DEBUG -Wduplicated-branches -Wimplicit-fallthrough 
-Wmisleading-indentation -Wstrict-prototypes -Wunused -Wno-unused-parameter 
-Wno-bad-function-cast -Wno-cast-function-type -Wno-pedantic 
-Wno-format-zero-length -Werror=declaration-after-statement -Werror=format=2 
-Werror=implicit-function-declaration -Werror=init-self 
-Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith', 
'--ldflags=-L/home/kbrown/src/glib/cygbuild/gio 
-Wl,-rpath,/home/kbrown/src/glib/cygbuild/gio 
-L/home/kbrown/src/glib/cygbuild/glib 
-Wl,-rpath,/home/kbrown/src/glib/cygbuild/glib 
-L/home/kbrown/src/glib/cygbuild/gobject 
-Wl,-rpath,/home/kbrown/src/glib/cygbuild/gobject 
-L/home/kbrown/src/glib/cygbuild/gmodule 
-Wl,-rpath,/home/kbrown/src/glib/cygbuild/gmodule -lgio-2.0 -lgmodule-2.0 
-lglib-2.0 -lgobject-2.0 -lz -pthread -lintl -lpcre -liconv -lffi', '--cc=cc', 
'--ld=cc', '--output-dir=/home/kbrown/src/glib/cygbuild/docs/reference/gio'] 
failed with status 127

I'll see what I can figure out, but as I said, it doesn't look to me like a 
meson issue.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
> On 5/31/2020 4:52 PM, Jon Turney wrote:
>> On 29/05/2020 16:54, Jon Turney wrote:
>>> On 27/05/2020 21:32, Ken Brown via Cygwin-apps wrote:
>>>> It looks like I've bumped into a variation of this bug.  While 
>>>> attempting to build the documentation for the latest glib2.0 
>>>> release, I got the following:
>>>>
>>>> FAILED: docs/reference/gobject/gobject-decl.txt
>>>> /usr/bin/meson --internal exe --unpickle 
>>>> /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat 
>>>>
>>>> ['/usr/bin/meson', '--internal', 'gtkdoc', 
>>>> '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', 
>>>> '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', 
>>>> '--subdir=docs/reference/gobject', '--headerdirs=gobject', 
>>>> '--mainfile=gobject-docs.xml', '--modulename=gobject', '--
>>>>
>>>> [...]
>>>>
>>>> /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', 
>>>> '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread 
>>>> -I@BUILD_ROOT@/. -I../. -I@BUILD_ROOT@/glib -I../glib 
>>>> -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs
>>>>
>>>> [...]
>>>>
>>>> So @BUILD_ROOT@ didn't get replaced by the build root after pickling 
>>>> and unpickling.  Needless to say, this produced errors like:
>>>>
>>>> cc1: error: @BUILD_ROOT@/glib: No such file or directory 
>>>> [-Werror=missing-include-dirs]
>>>>
>>>> I can give you a precise recipe for reproducing this bug if it would 
>>>> help your debugging.
>>>
>>> Definitely a bug.  I'll see if I can take a look at it this weekend.
>>
>> https://github.com/mesonbuild/meson/pull/7229
>>
>> I made a meson 0.54.2-2 test package with those patches.
> 
> Thanks!  That gets me much further in the glib build.  I still have a 
> problem with the docs, but I have no reason to think it's a meson bug.  
> When running 'ninja install' I get the following:
> 
> Building documentation for gio
> ERROR: Error in gtkdoc helper script:
> 
> ERROR: ['/usr/bin/gtkdoc-scangobj', 
> '--types=/home/kbrown/src/glib/cygbuild/docs/reference/gio/gio.types', 
> '--module=gio', '--run=', '--cflags=-I/home/kbrown/src/glib/cygbuild/gio 
> -I/home/kbrown/src/glib/gio -pthread 
> -I/home/kbrown/src/glib/cygbuild/gmodule -I/home/kbrown/src/glib/gmodule 
> -I/home/kbrown/src/glib/cygbuild/. -I/home/kbrown/src/glib/. 
> -I/home/kbrown/src/glib/cygbuild/glib -I/home/kbrown/src/glib/glib 
> -I/home/kbrown/src/glib/cygbuild/gobject -I/home/kbrown/src/glib/gobject 
> -D_GNU_SOURCE -fno-strict-aliasing -DG_ENABLE_DEBUG 
> -Wduplicated-branches -Wimplicit-fallthrough -Wmisleading-indentation 
> -Wstrict-prototypes -Wunused -Wno-unused-parameter 
> -Wno-bad-function-cast -Wno-cast-function-type -Wno-pedantic 
> -Wno-format-zero-length -Werror=declaration-after-statement 
> -Werror=format=2 -Werror=implicit-function-declaration -Werror=init-self 
> -Werror=missing-include-dirs -Werror=missing-prototypes 
> -Werror=pointer-arith', '--ldflags=-L/home/kbrown/src/glib/cygbuild/gio 
> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gio 
> -L/home/kbrown/src/glib/cygbuild/glib 
> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/glib 
> -L/home/kbrown/src/glib/cygbuild/gobject 
> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gobject 
> -L/home/kbrown/src/glib/cygbuild/gmodule 
> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gmodule -lgio-2.0 
> -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lz -pthread -lintl -lpcre 
> -liconv -lffi', '--cc=cc', '--ld=cc', 
> '--output-dir=/home/kbrown/src/glib/cygbuild/docs/reference/gio'] failed 
> with status 127
> 
> I'll see what I can figure out, but as I said, it doesn't look to me 
> like a meson issue.

This looks like the problem that my second patch was supposed to fix, so 
I guess I've messed up somewhere.

(gtkdoc-scangobj builds and runs a executable linked with the gio shared 
library.  meson needs to set PATH appropriately so that shared library 
can be loaded)

Re: Help needed with gobject-introspection

[Jon Turney]

On 01/06/2020 12:30, Jon Turney wrote:
> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>
>> Thanks!  That gets me much further in the glib build.  I still have a 
>> problem with the docs, but I have no reason to think it's a meson bug. 
>> When running 'ninja install' I get the following:
>>
>> Building documentation for gio
>> ERROR: Error in gtkdoc helper script:
>>
>> ERROR: ['/usr/bin/gtkdoc-scangobj', 
>> '--types=/home/kbrown/src/glib/cygbuild/docs/reference/gio/gio.types', 
>> '--module=gio', '--run=', 
>> '--cflags=-I/home/kbrown/src/glib/cygbuild/gio 
>> -I/home/kbrown/src/glib/gio -pthread 
>> -I/home/kbrown/src/glib/cygbuild/gmodule 
>> -I/home/kbrown/src/glib/gmodule -I/home/kbrown/src/glib/cygbuild/. 
>> -I/home/kbrown/src/glib/. -I/home/kbrown/src/glib/cygbuild/glib 
>> -I/home/kbrown/src/glib/glib -I/home/kbrown/src/glib/cygbuild/gobject 
>> -I/home/kbrown/src/glib/gobject -D_GNU_SOURCE -fno-strict-aliasing 
>> -DG_ENABLE_DEBUG -Wduplicated-branches -Wimplicit-fallthrough 
>> -Wmisleading-indentation -Wstrict-prototypes -Wunused 
>> -Wno-unused-parameter -Wno-bad-function-cast -Wno-cast-function-type 
>> -Wno-pedantic -Wno-format-zero-length 
>> -Werror=declaration-after-statement -Werror=format=2 
>> -Werror=implicit-function-declaration -Werror=init-self 
>> -Werror=missing-include-dirs -Werror=missing-prototypes 
>> -Werror=pointer-arith', 
>> '--ldflags=-L/home/kbrown/src/glib/cygbuild/gio 
>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gio 
>> -L/home/kbrown/src/glib/cygbuild/glib 
>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/glib 
>> -L/home/kbrown/src/glib/cygbuild/gobject 
>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gobject 
>> -L/home/kbrown/src/glib/cygbuild/gmodule 
>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gmodule -lgio-2.0 
>> -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lz -pthread -lintl -lpcre 
>> -liconv -lffi', '--cc=cc', '--ld=cc', 
>> '--output-dir=/home/kbrown/src/glib/cygbuild/docs/reference/gio'] 
>> failed with status 127
>>
>> I'll see what I can figure out, but as I said, it doesn't look to me 
>> like a meson issue.
> 
> This looks like the problem that my second patch was supposed to fix, so 
> I guess I've messed up somewhere.
> 
> (gtkdoc-scangobj builds and runs a executable linked with the gio shared 
> library.  meson needs to set PATH appropriately so that shared library 
> can be loaded)
> 

Hmmm.. I can't reproduce this.

Using my meson 0.54.2-2 package, I managed to build glib (from the 
2.64.3 tag in the glib repository) configured with -Dgtk_doc=true.

Re: Help needed with gobject-introspection

[Ken Brown]

On 6/2/2020 10:26 AM, Jon Turney wrote:
> On 01/06/2020 12:30, Jon Turney wrote:
>> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>>
>>> Thanks!  That gets me much further in the glib build.  I still have a problem 
>>> with the docs, but I have no reason to think it's a meson bug. When running 
>>> 'ninja install' I get the following:
>>>
>>> Building documentation for gio
>>> ERROR: Error in gtkdoc helper script:
>>>
>>> ERROR: ['/usr/bin/gtkdoc-scangobj', 
>>> '--types=/home/kbrown/src/glib/cygbuild/docs/reference/gio/gio.types', 
>>> '--module=gio', '--run=', '--cflags=-I/home/kbrown/src/glib/cygbuild/gio 
>>> -I/home/kbrown/src/glib/gio -pthread -I/home/kbrown/src/glib/cygbuild/gmodule 
>>> -I/home/kbrown/src/glib/gmodule -I/home/kbrown/src/glib/cygbuild/. 
>>> -I/home/kbrown/src/glib/. -I/home/kbrown/src/glib/cygbuild/glib 
>>> -I/home/kbrown/src/glib/glib -I/home/kbrown/src/glib/cygbuild/gobject 
>>> -I/home/kbrown/src/glib/gobject -D_GNU_SOURCE -fno-strict-aliasing 
>>> -DG_ENABLE_DEBUG -Wduplicated-branches -Wimplicit-fallthrough 
>>> -Wmisleading-indentation -Wstrict-prototypes -Wunused -Wno-unused-parameter 
>>> -Wno-bad-function-cast -Wno-cast-function-type -Wno-pedantic 
>>> -Wno-format-zero-length -Werror=declaration-after-statement -Werror=format=2 
>>> -Werror=implicit-function-declaration -Werror=init-self 
>>> -Werror=missing-include-dirs -Werror=missing-prototypes 
>>> -Werror=pointer-arith', '--ldflags=-L/home/kbrown/src/glib/cygbuild/gio 
>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gio 
>>> -L/home/kbrown/src/glib/cygbuild/glib 
>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/glib 
>>> -L/home/kbrown/src/glib/cygbuild/gobject 
>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gobject 
>>> -L/home/kbrown/src/glib/cygbuild/gmodule 
>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gmodule -lgio-2.0 -lgmodule-2.0 
>>> -lglib-2.0 -lgobject-2.0 -lz -pthread -lintl -lpcre -liconv -lffi', 
>>> '--cc=cc', '--ld=cc', 
>>> '--output-dir=/home/kbrown/src/glib/cygbuild/docs/reference/gio'] failed with 
>>> status 127
>>>
>>> I'll see what I can figure out, but as I said, it doesn't look to me like a 
>>> meson issue.
>>
>> This looks like the problem that my second patch was supposed to fix, so I 
>> guess I've messed up somewhere.
>>
>> (gtkdoc-scangobj builds and runs a executable linked with the gio shared 
>> library.  meson needs to set PATH appropriately so that shared library can be 
>> loaded)
>>
> 
> Hmmm.. I can't reproduce this.
> 
> Using my meson 0.54.2-2 package, I managed to build glib (from the 2.64.3 tag in 
> the glib repository) configured with -Dgtk_doc=true.

Did you run 'ninja install'?  The problem doesn't show up until you do that.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 02/06/2020 15:31, Ken Brown via Cygwin-apps wrote:
> On 6/2/2020 10:26 AM, Jon Turney wrote:
>> On 01/06/2020 12:30, Jon Turney wrote:
>>> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>>>
>>>> Thanks!  That gets me much further in the glib build.  I still have 
>>>> a problem with the docs, but I have no reason to think it's a meson 
>>>> bug. When running 'ninja install' I get the following:
>>>>
>>>> Building documentation for gio
>>>> ERROR: Error in gtkdoc helper script:
>>>>
>>>> ERROR: ['/usr/bin/gtkdoc-scangobj', 
>>>> '--types=/home/kbrown/src/glib/cygbuild/docs/reference/gio/gio.types', 
>>>> '--module=gio', '--run=', 
>>>> '--cflags=-I/home/kbrown/src/glib/cygbuild/gio 
>>>> -I/home/kbrown/src/glib/gio -pthread 
>>>> -I/home/kbrown/src/glib/cygbuild/gmodule 
>>>> -I/home/kbrown/src/glib/gmodule -I/home/kbrown/src/glib/cygbuild/. 
>>>> -I/home/kbrown/src/glib/. -I/home/kbrown/src/glib/cygbuild/glib 
>>>> -I/home/kbrown/src/glib/glib 
>>>> -I/home/kbrown/src/glib/cygbuild/gobject 
>>>> -I/home/kbrown/src/glib/gobject -D_GNU_SOURCE -fno-strict-aliasing 
>>>> -DG_ENABLE_DEBUG -Wduplicated-branches -Wimplicit-fallthrough 
>>>> -Wmisleading-indentation -Wstrict-prototypes -Wunused 
>>>> -Wno-unused-parameter -Wno-bad-function-cast -Wno-cast-function-type 
>>>> -Wno-pedantic -Wno-format-zero-length 
>>>> -Werror=declaration-after-statement -Werror=format=2 
>>>> -Werror=implicit-function-declaration -Werror=init-self 
>>>> -Werror=missing-include-dirs -Werror=missing-prototypes 
>>>> -Werror=pointer-arith', 
>>>> '--ldflags=-L/home/kbrown/src/glib/cygbuild/gio 
>>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gio 
>>>> -L/home/kbrown/src/glib/cygbuild/glib 
>>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/glib 
>>>> -L/home/kbrown/src/glib/cygbuild/gobject 
>>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gobject 
>>>> -L/home/kbrown/src/glib/cygbuild/gmodule 
>>>> -Wl,-rpath,/home/kbrown/src/glib/cygbuild/gmodule -lgio-2.0 
>>>> -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lz -pthread -lintl -lpcre 
>>>> -liconv -lffi', '--cc=cc', '--ld=cc', 
>>>> '--output-dir=/home/kbrown/src/glib/cygbuild/docs/reference/gio'] 
>>>> failed with status 127
>>>>
>>>> I'll see what I can figure out, but as I said, it doesn't look to me 
>>>> like a meson issue.
>>>
>>> This looks like the problem that my second patch was supposed to fix, 
>>> so I guess I've messed up somewhere.
>>>
>>> (gtkdoc-scangobj builds and runs a executable linked with the gio 
>>> shared library.  meson needs to set PATH appropriately so that shared 
>>> library can be loaded)
>>>
>>
>> Hmmm.. I can't reproduce this.
>>
>> Using my meson 0.54.2-2 package, I managed to build glib (from the 
>> 2.64.3 tag in the glib repository) configured with -Dgtk_doc=true.
> 
> Did you run 'ninja install'?  The problem doesn't show up until you do 
> that.

Sigh, yes, you're right.  It gets built during 'all', and succeeds, and 
then gets built again during 'install', in a slightly different way, 
which fails.

Re: Help needed with gobject-introspection

[Jon Turney]

On 02/06/2020 22:28, Jon Turney wrote:
> On 02/06/2020 15:31, Ken Brown via Cygwin-apps wrote:
>> On 6/2/2020 10:26 AM, Jon Turney wrote:
>>> On 01/06/2020 12:30, Jon Turney wrote:
>>>> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>>>>
>>>>> I'll see what I can figure out, but as I said, it doesn't look to 
>>>>> me like a meson issue.
>>>>
>>>> This looks like the problem that my second patch was supposed to 
>>>> fix, so I guess I've messed up somewhere.
>>>>
>>>> (gtkdoc-scangobj builds and runs a executable linked with the gio 
>>>> shared library.  meson needs to set PATH appropriately so that 
>>>> shared library can be loaded)
>>>
>>> Hmmm.. I can't reproduce this.
>>>
>>> Using my meson 0.54.2-2 package, I managed to build glib (from the 
>>> 2.64.3 tag in the glib repository) configured with -Dgtk_doc=true.
>>
>> Did you run 'ninja install'?  The problem doesn't show up until you do 
>> that.
> 
> Sigh, yes, you're right.  It gets built during 'all', and succeeds, and 
> then gets built again during 'install', in a slightly different way, 
> which fails.
Added another patch to that PR which should fix gtkdoc documentation 
which is built at install-time.

Uploaded a meson 0.54.2-3 test package.

Re: Help needed with gobject-introspection

[Ken Brown]

On 6/3/2020 12:51 PM, Jon Turney wrote:
> On 02/06/2020 22:28, Jon Turney wrote:
>> On 02/06/2020 15:31, Ken Brown via Cygwin-apps wrote:
>>> On 6/2/2020 10:26 AM, Jon Turney wrote:
>>>> On 01/06/2020 12:30, Jon Turney wrote:
>>>>> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>>>>>
>>>>>> I'll see what I can figure out, but as I said, it doesn't look to me like 
>>>>>> a meson issue.
>>>>>
>>>>> This looks like the problem that my second patch was supposed to fix, so I 
>>>>> guess I've messed up somewhere.
>>>>>
>>>>> (gtkdoc-scangobj builds and runs a executable linked with the gio shared 
>>>>> library.  meson needs to set PATH appropriately so that shared library can 
>>>>> be loaded)
>>>>
>>>> Hmmm.. I can't reproduce this.
>>>>
>>>> Using my meson 0.54.2-2 package, I managed to build glib (from the 2.64.3 
>>>> tag in the glib repository) configured with -Dgtk_doc=true.
>>>
>>> Did you run 'ninja install'?  The problem doesn't show up until you do that.
>>
>> Sigh, yes, you're right.  It gets built during 'all', and succeeds, and then 
>> gets built again during 'install', in a slightly different way, which fails.
> Added another patch to that PR which should fix gtkdoc documentation which is 
> built at install-time.
> 
> Uploaded a meson 0.54.2-3 test package.

That fixes it!  Thanks.

Ken

Re: Help needed with gobject-introspection

[Ken Brown]

On 6/3/2020 2:30 PM, Ken Brown via Cygwin-apps wrote:
> On 6/3/2020 12:51 PM, Jon Turney wrote:
>> On 02/06/2020 22:28, Jon Turney wrote:
>>> On 02/06/2020 15:31, Ken Brown via Cygwin-apps wrote:
>>>> On 6/2/2020 10:26 AM, Jon Turney wrote:
>>>>> On 01/06/2020 12:30, Jon Turney wrote:
>>>>>> On 01/06/2020 00:58, Ken Brown via Cygwin-apps wrote:
>>>>>>>
>>>>>>> I'll see what I can figure out, but as I said, it doesn't look to me like 
>>>>>>> a meson issue.
>>>>>>
>>>>>> This looks like the problem that my second patch was supposed to fix, so I 
>>>>>> guess I've messed up somewhere.
>>>>>>
>>>>>> (gtkdoc-scangobj builds and runs a executable linked with the gio shared 
>>>>>> library.  meson needs to set PATH appropriately so that shared library can 
>>>>>> be loaded)
>>>>>
>>>>> Hmmm.. I can't reproduce this.
>>>>>
>>>>> Using my meson 0.54.2-2 package, I managed to build glib (from the 2.64.3 
>>>>> tag in the glib repository) configured with -Dgtk_doc=true.
>>>>
>>>> Did you run 'ninja install'?  The problem doesn't show up until you do that.
>>>
>>> Sigh, yes, you're right.  It gets built during 'all', and succeeds, and then 
>>> gets built again during 'install', in a slightly different way, which fails.
>> Added another patch to that PR which should fix gtkdoc documentation which is 
>> built at install-time.
>>
>> Uploaded a meson 0.54.2-3 test package.
> 
> That fixes it!  Thanks.

I think I might have bumped into another meson/introspection/pickling bug, this 
time in connection with harfbuzz.  The supported build system for harfbuzz is 
still autotools.  But they're planning to move to meson, so I decided to get a 
head start and try the meson build, which fails as follows:

[230/257] Generating HarfBuzz-0.0.gir with a meson_exe.py custom command
FAILED: src/HarfBuzz-0.0.gir
/usr/bin/meson --internal exe --unpickle 
/tmp/harfbuzz-2.6.7/build/meson-private/meson_exe_g-ir-scanner_2a1d762c64dc7a0dcba76211733b53a4f7f14918.dat
[...]
ERROR: can't resolve libraries to shared libraries: harfbuzz-gobject
g-ir-scanner: link: cc -o 
/tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.exe 
/tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.o -L. -lharfbuzz 
-lharfbuzz-gobject -lm -lglib-2.0 -lintl -lgobject-2.0 -lcairo -lfreetype 
-lgraphite2 -lfontconfig -L/tmp/harfbuzz-2.6.7/build/src 
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
-Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -lgio-2.0 -lgobject-2.0 
-Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl

To reproduce:

wget 
https://github.com/harfbuzz/harfbuzz/releases/download/2.6.7/harfbuzz-2.6.7.tar.xz

tar -xf harfbuzz-2.6.7.tar.xz

cd harfbuzz-2.6.7

meson \
   -Dintrospection=enabled \
   -Dcairo=enabled \
   -Dfontconfig=enabled \
   -Dfreetype=enabled \
   -Dglib=enabled \
   -Dgobject=enabled \
   -Dgraphite=enabled \
   -Dicu=enabled \
   build

cd build

ninja

Re: Help needed with gobject-introspection

[Jon Turney]

On 06/06/2020 15:15, Ken Brown via Cygwin-apps wrote:
> 
> I think I might have bumped into another meson/introspection/pickling 
> bug, this time in connection with harfbuzz.  The supported build system 
> for harfbuzz is still autotools.  But they're planning to move to meson, 
> so I decided to get a head start and try the meson build, which fails as 
> follows:
> 
> [230/257] Generating HarfBuzz-0.0.gir with a meson_exe.py custom command
> FAILED: src/HarfBuzz-0.0.gir
> /usr/bin/meson --internal exe --unpickle 
> /tmp/harfbuzz-2.6.7/build/meson-private/meson_exe_g-ir-scanner_2a1d762c64dc7a0dcba76211733b53a4f7f14918.dat 
> 
> [...]
> ERROR: can't resolve libraries to shared libraries: harfbuzz-gobject
> g-ir-scanner: link: cc -o 
> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.exe 
> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.o -L. 
> -lharfbuzz -lharfbuzz-gobject -lm -lglib-2.0 -lintl -lgobject-2.0 
> -lcairo -lfreetype -lgraphite2 -lfontconfig 
> -L/tmp/harfbuzz-2.6.7/build/src -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src 
> -L/tmp/harfbuzz-2.6.7/build/src -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src 
> -L/tmp/harfbuzz-2.6.7/build/src -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src 
> -lgio-2.0 -lgobject-2.0 -Wl,--export-all-symbols -lgmodule-2.0 
> -lglib-2.0 -lintl
[...]

Thanks for the reproduction steps.

To debug: hack meson to get it to disgorge the pickled command it's 
executing, then you can run the failing g-ir-scanner command line while 
poking at things in /usr/lib/gobject-introspection/giscanner/

This actually looks like a bug in 'g-ir-scanner --no-libtool' (which 
obviously isn't usually exercised by an autotools build), failing in 
this particular case.

It looks to match the following list of regexes:

> ([^\s]*cyg*harfbuzz[^A-Za-z0-9_][^\s\(\)]*)
> ([^\s]*cyg*harfbuzz\-gobject[^A-Za-z0-9_][^\s\(\)]*)

against ldd output like this, to extract the shared library names:

>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff916d80000)
>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff916660000)
>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff914a20000)
>         cyggmodule-2.0-0.dll => /usr/bin/cyggmodule-2.0-0.dll (0x3e0590000)
>         cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
>         cygharfbuzz-gobject-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-gobject-0.dll (0x4389e0000)
>         cyggio-2.0-0.dll => /usr/bin/cyggio-2.0-0.dll (0x3e0f40000)
>         cygglib-2.0-0.dll => /usr/bin/cygglib-2.0-0.dll (0x3e0870000)
>         cyggobject-2.0-0.dll => /usr/bin/cyggobject-2.0-0.dll (0x3dff50000)
>         cygharfbuzz-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-0.dll (0x4408d0000)
>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3cf150000)
>         cygz.dll => /usr/bin/cygz.dll (0x3bc750000)
>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dbec0000)
>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x4629a0000)
>         cygffi-6.dll => /usr/bin/cygffi-6.dll (0x3e3fd0000)
>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa0000)
>         cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x451720000)
>         cyggraphite2-3.dll => /usr/bin/cyggraphite2-3.dll (0x5f6ba0000)
>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e9980000)
>         cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3c58d0000)
>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x57b190000)

Unfortunately, the first regex matches the cygharfbuzz-gobject line, 
leaving the second regex unmatched.

We have to allow a '-' to appear after the library name, as that 
introduces a soversion, so I worked around this by patching 
/usr/lib/gobject-introspection/giscanner/shlibs.c like this:

--- shlibs.py~  2018-02-11 23:15:03.000000000 +0000
+++ shlibs.py   2020-06-11 22:28:07.901294700 +0100
@@ -62,7 +62,7 @@
      if platform.system() == 'Darwin':
          pattern = "([^\s]*lib*%s[^A-Za-z0-9_-][^\s\(\)]*)"
      elif platform.platform().startswith('CYGWIN'):
-        pattern = "([^\s]*cyg*%s[^A-Za-z0-9_][^\s\(\)]*)"
+        pattern = "([^\s]*cyg%s[-.0-9]*\.[^\s\(\)]*)"
      return re.compile(pattern % re.escape(library_name))

But this all seems very fragile though, so I'm not sure if that's the 
right way to fix this.

(This 'if cygwin' case is coming from gobject-introspection package in 
[1], it's not in upstream)

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git;a=blob;f=1.46.0-cygwin.patch;h=a03271ea17e0d167eba7627ddf5d4303bbde9871;hb=4e3b8bd140db78ee35f29ee3d07ff3715416e259#l93

Re: Help needed with gobject-introspection

[Ken Brown]

On 6/11/2020 5:39 PM, Jon Turney wrote:
> 
> On 06/06/2020 15:15, Ken Brown via Cygwin-apps wrote:
>>
>> I think I might have bumped into another meson/introspection/pickling bug, 
>> this time in connection with harfbuzz.  The supported build system for 
>> harfbuzz is still autotools.  But they're planning to move to meson, so I 
>> decided to get a head start and try the meson build, which fails as follows:
>>
>> [230/257] Generating HarfBuzz-0.0.gir with a meson_exe.py custom command
>> FAILED: src/HarfBuzz-0.0.gir
>> /usr/bin/meson --internal exe --unpickle 
>> /tmp/harfbuzz-2.6.7/build/meson-private/meson_exe_g-ir-scanner_2a1d762c64dc7a0dcba76211733b53a4f7f14918.dat 
>>
>> [...]
>> ERROR: can't resolve libraries to shared libraries: harfbuzz-gobject
>> g-ir-scanner: link: cc -o 
>> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.exe 
>> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.o -L. -lharfbuzz 
>> -lharfbuzz-gobject -lm -lglib-2.0 -lintl -lgobject-2.0 -lcairo -lfreetype 
>> -lgraphite2 -lfontconfig -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -lgio-2.0 -lgobject-2.0 
>> -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
> [...]
> 
> Thanks for the reproduction steps.
> 
> To debug: hack meson to get it to disgorge the pickled command it's executing, 
> then you can run the failing g-ir-scanner command line while poking at things in 
> /usr/lib/gobject-introspection/giscanner/
> 
> This actually looks like a bug in 'g-ir-scanner --no-libtool' (which obviously 
> isn't usually exercised by an autotools build), failing in this particular case.
> 
> It looks to match the following list of regexes:
> 
>> ([^\s]*cyg*harfbuzz[^A-Za-z0-9_][^\s\(\)]*)
>> ([^\s]*cyg*harfbuzz\-gobject[^A-Za-z0-9_][^\s\(\)]*)
> 
> against ldd output like this, to extract the shared library names:
> 
>>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff916d80000)
>>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
>> (0x7ff916660000)
>>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
>> (0x7ff914a20000)
>>         cyggmodule-2.0-0.dll => /usr/bin/cyggmodule-2.0-0.dll (0x3e0590000)
>>         cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
>>         cygharfbuzz-gobject-0.dll => 
>> /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-gobject-0.dll (0x4389e0000)
>>         cyggio-2.0-0.dll => /usr/bin/cyggio-2.0-0.dll (0x3e0f40000)
>>         cygglib-2.0-0.dll => /usr/bin/cygglib-2.0-0.dll (0x3e0870000)
>>         cyggobject-2.0-0.dll => /usr/bin/cyggobject-2.0-0.dll (0x3dff50000)
>>         cygharfbuzz-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-0.dll 
>> (0x4408d0000)
>>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3cf150000)
>>         cygz.dll => /usr/bin/cygz.dll (0x3bc750000)
>>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dbec0000)
>>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x4629a0000)
>>         cygffi-6.dll => /usr/bin/cygffi-6.dll (0x3e3fd0000)
>>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa0000)
>>         cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x451720000)
>>         cyggraphite2-3.dll => /usr/bin/cyggraphite2-3.dll (0x5f6ba0000)
>>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e9980000)
>>         cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3c58d0000)
>>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x57b190000)
> 
> Unfortunately, the first regex matches the cygharfbuzz-gobject line, leaving the 
> second regex unmatched.
> 
> We have to allow a '-' to appear after the library name, as that introduces a 
> soversion, so I worked around this by patching 
> /usr/lib/gobject-introspection/giscanner/shlibs.c like this:
> 
> --- shlibs.py~  2018-02-11 23:15:03.000000000 +0000
> +++ shlibs.py   2020-06-11 22:28:07.901294700 +0100
> @@ -62,7 +62,7 @@
>       if platform.system() == 'Darwin':
>           pattern = "([^\s]*lib*%s[^A-Za-z0-9_-][^\s\(\)]*)"
>       elif platform.platform().startswith('CYGWIN'):
> -        pattern = "([^\s]*cyg*%s[^A-Za-z0-9_][^\s\(\)]*)"
> +        pattern = "([^\s]*cyg%s[-.0-9]*\.[^\s\(\)]*)"
>       return re.compile(pattern % re.escape(library_name))
> 
> But this all seems very fragile though, so I'm not sure if that's the right way 
> to fix this.
> 
> (This 'if cygwin' case is coming from gobject-introspection package in [1], it's 
> not in upstream)
> 
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git;a=blob;f=1.46.0-cygwin.patch;h=a03271ea17e0d167eba7627ddf5d4303bbde9871;hb=4e3b8bd140db78ee35f29ee3d07ff3715416e259#l93 

Thanks, Jon!  Just as your mail came in, I was staring at the regex for 
harfbuzz-gobject in shlibs.py, trying to understand why it wasn't matched.  It 
never occurred to me that the cygharfbuzz-gobject-0.dll line in the ldd output 
was being used to match the regex for harfbuzz rather than the one for 
harfbuzz-gobject.  What a mess.

Thanks again.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 12/06/2020 00:23, Ken Brown via Cygwin-apps wrote:
> On 6/11/2020 5:39 PM, Jon Turney wrote:
[...]
>> --- shlibs.py~  2018-02-11 23:15:03.000000000 +0000
>> +++ shlibs.py   2020-06-11 22:28:07.901294700 +0100
>> @@ -62,7 +62,7 @@
>>       if platform.system() == 'Darwin':
>>           pattern = "([^\s]*lib*%s[^A-Za-z0-9_-][^\s\(\)]*)"
>>       elif platform.platform().startswith('CYGWIN'):
>> -        pattern = "([^\s]*cyg*%s[^A-Za-z0-9_][^\s\(\)]*)"
>> +        pattern = "([^\s]*cyg%s[-.0-9]*\.[^\s\(\)]*)"
>>       return re.compile(pattern % re.escape(library_name))
>>
>> But this all seems very fragile though, so I'm not sure if that's the 
>> right way to fix this.
>>
>> (This 'if cygwin' case is coming from gobject-introspection package in 
>> [1], it's not in upstream)
>>
>> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gobject-introspection.git;a=blob;f=1.46.0-cygwin.patch;h=a03271ea17e0d167eba7627ddf5d4303bbde9871;hb=4e3b8bd140db78ee35f29ee3d07ff3715416e259#l93 
> 
> Thanks, Jon!  Just as your mail came in, I was staring at the regex for 
> harfbuzz-gobject in shlibs.py, trying to understand why it wasn't 
> matched.  It never occurred to me that the cygharfbuzz-gobject-0.dll 
> line in the ldd output was being used to match the regex for harfbuzz 
> rather than the one for harfbuzz-gobject.  What a mess.

Yeah, I went around in circles on that a few times myself :)

Re: Help needed with gobject-introspection

[Ken Brown]

On 6/11/2020 5:39 PM, Jon Turney wrote:
> 
> On 06/06/2020 15:15, Ken Brown via Cygwin-apps wrote:
>>
>> I think I might have bumped into another meson/introspection/pickling bug, 
>> this time in connection with harfbuzz.  The supported build system for 
>> harfbuzz is still autotools.  But they're planning to move to meson, so I 
>> decided to get a head start and try the meson build, which fails as follows:
>>
>> [230/257] Generating HarfBuzz-0.0.gir with a meson_exe.py custom command
>> FAILED: src/HarfBuzz-0.0.gir
>> /usr/bin/meson --internal exe --unpickle 
>> /tmp/harfbuzz-2.6.7/build/meson-private/meson_exe_g-ir-scanner_2a1d762c64dc7a0dcba76211733b53a4f7f14918.dat 
>>
>> [...]
>> ERROR: can't resolve libraries to shared libraries: harfbuzz-gobject
>> g-ir-scanner: link: cc -o 
>> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.exe 
>> /tmp/harfbuzz-2.6.7/build/tmp-introspectKdIYKJ/HarfBuzz-0.0.o -L. -lharfbuzz 
>> -lharfbuzz-gobject -lm -lglib-2.0 -lintl -lgobject-2.0 -lcairo -lfreetype 
>> -lgraphite2 -lfontconfig -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -L/tmp/harfbuzz-2.6.7/build/src 
>> -Wl,-rpath,/tmp/harfbuzz-2.6.7/build/src -lgio-2.0 -lgobject-2.0 
>> -Wl,--export-all-symbols -lgmodule-2.0 -lglib-2.0 -lintl
> [...]
> 
> Thanks for the reproduction steps.
> 
> To debug: hack meson to get it to disgorge the pickled command it's executing, 
> then you can run the failing g-ir-scanner command line while poking at things in 
> /usr/lib/gobject-introspection/giscanner/
> 
> This actually looks like a bug in 'g-ir-scanner --no-libtool' (which obviously 
> isn't usually exercised by an autotools build), failing in this particular case.
> 
> It looks to match the following list of regexes:
> 
>> ([^\s]*cyg*harfbuzz[^A-Za-z0-9_][^\s\(\)]*)
>> ([^\s]*cyg*harfbuzz\-gobject[^A-Za-z0-9_][^\s\(\)]*)
> 
> against ldd output like this, to extract the shared library names:
> 
>>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff916d80000)
>>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
>> (0x7ff916660000)
>>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
>> (0x7ff914a20000)
>>         cyggmodule-2.0-0.dll => /usr/bin/cyggmodule-2.0-0.dll (0x3e0590000)
>>         cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
>>         cygharfbuzz-gobject-0.dll => 
>> /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-gobject-0.dll (0x4389e0000)
>>         cyggio-2.0-0.dll => /usr/bin/cyggio-2.0-0.dll (0x3e0f40000)
>>         cygglib-2.0-0.dll => /usr/bin/cygglib-2.0-0.dll (0x3e0870000)
>>         cyggobject-2.0-0.dll => /usr/bin/cyggobject-2.0-0.dll (0x3dff50000)
>>         cygharfbuzz-0.dll => /work/harfbuzz-2.6.7/_build/src/cygharfbuzz-0.dll 
>> (0x4408d0000)
>>         cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3cf150000)
>>         cygz.dll => /usr/bin/cygz.dll (0x3bc750000)
>>         cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3dbec0000)
>>         cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x4629a0000)
>>         cygffi-6.dll => /usr/bin/cygffi-6.dll (0x3e3fd0000)
>>         cyggcc_s-seh-1.dll => /usr/bin/cyggcc_s-seh-1.dll (0x50caa0000)
>>         cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x451720000)
>>         cyggraphite2-3.dll => /usr/bin/cyggraphite2-3.dll (0x5f6ba0000)
>>         cygbz2-1.dll => /usr/bin/cygbz2-1.dll (0x3e9980000)
>>         cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3c58d0000)
>>         cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x57b190000)
> 
> Unfortunately, the first regex matches the cygharfbuzz-gobject line, leaving the 
> second regex unmatched.
> 
> We have to allow a '-' to appear after the library name, as that introduces a 
> soversion, so I worked around this by patching 
> /usr/lib/gobject-introspection/giscanner/shlibs.c like this:
> 
> --- shlibs.py~  2018-02-11 23:15:03.000000000 +0000
> +++ shlibs.py   2020-06-11 22:28:07.901294700 +0100
> @@ -62,7 +62,7 @@
>       if platform.system() == 'Darwin':
>           pattern = "([^\s]*lib*%s[^A-Za-z0-9_-][^\s\(\)]*)"
>       elif platform.platform().startswith('CYGWIN'):
> -        pattern = "([^\s]*cyg*%s[^A-Za-z0-9_][^\s\(\)]*)"
> +        pattern = "([^\s]*cyg%s[-.0-9]*\.[^\s\(\)]*)"
>       return re.compile(pattern % re.escape(library_name))
> 
> But this all seems very fragile though, so I'm not sure if that's the right way 
> to fix this.

Jon,

No one has suggested a better fix, so I think we should get your fix into the 
distro.  It's not urgent, because harfbuzz still supports both autotools and 
meson, but they're encouraging packagers to move toward meson.

How do you think we should proceed?  Are you interested in adopting 
gobject-introspection?  Alternatively, one of us could do a non-maintainer 
upload while we wait for a volunteer.

Ken

Re: Help needed with gobject-introspection

[Jon Turney]

On 01/08/2020 19:01, Ken Brown via Cygwin-apps wrote:
> 
> No one has suggested a better fix, so I think we should get your fix 
> into the distro.  It's not urgent, because harfbuzz still supports both 
> autotools and meson, but they're encouraging packagers to move toward 
> meson.

I think the real fix is for g-ir-scanner not to do this.

(To be clearer, I think the invoking build system has, in nearly all 
cases, an accurate idea of the mapping g-ir-scanner is trying to 
discover here (between libraries named in linker -l options and the 
actual shared library filename?), and it should just have options to let 
the build system give it that information, rather these going through 
these contortions to try to work it out)

But since that seems unlikely to happen anytime soon, so I guess this is 
the best we can do.

> How do you think we should proceed?  Are you interested in adopting 
> gobject-introspection?  Alternatively, one of us could do a 
> non-maintainer upload while we wait for a volunteer.

Please go ahead with an NMU, if you have the time for it.