bitwiseworks / cmake-os2 Goto Github PK

According to this, the default path for the install target is /usr/local on Unix-like machines. The OS/2 build seems to fall into this category as well as this is exactly what I see. And it's completely wrong because it will install stuff into a wrong dir if the build drive does not match UNIXROOT (which usually the case on dev machines) and it will never be found by tools (i.e. cmake itself which looks into /@unixroot/usr/local/lib/cmake for modules by default in addition to /@unixroot/usr/lib/cmake.

The default install path should be therefore /@unixroot/usr/local instead of just /usr/local.

This breaks compilation, along with various attempts to use ipv6 throughout libuv.
I did install libav-devel but the cmake build doesn't seem to pick it up.

Btw "linguist" package is installed and "lrelease" tool work when invoked directly.

I look on both the release and experimental repos but all I see is the debuginfo for 2.15.3

ERROR with transaction check vs depsolve:python(abi) = 2.7 is needed by (installed) urlgrabber-3.10.1-10.oc00.noarchpython(abi) = 2.7 is needed by (installed) yum-utils-1.1.31-3.oc00.noarchpython(abi) = 2.7 is needed by (installed) python2-rpm-4.13.0-20.oc00.i686python(abi) = 2.7 is needed by (installed) yum-metadata-parser-1.1.4-7.oc00.i686python(abi) = 2.7 is needed by (installed) mercurial-2.5.2-1.oc00.pentium4python(abi) = 2.7 is needed by (installed) yum-3.4.3-14.oc00.pentium4/@unixroot/usr/bin/python2 is needed by (installed) hplip-3.19.8-3.oc00.i686python27.dll is needed by (installed) python2-rpm-4.13.0-20.oc00.i686python27.dll is needed by (installed) hplip-libs-3.19.8-3.oc00.i686python27.dll is needed by (installed) yum-metadata-parser-1.1.4-7.oc00.i686python27.dll is needed by (installed) mercurial-2.5.2-1.oc00.pentium4python(abi) = 2.7 is needed by python2-pycurl-7.44.1-3.oc00.pentium4python27.dll is needed by python2-pycurl-7.44.1-3.oc00.pentium4Please report this error at https://github.com/bitwiseworks/rpm-issues

Note python 2.7 is installed

Pretty sure adding : AND NOT OS2 at https://github.com/bitwiseworks/cmake-os2/blob/master/Modules/GenerateExportHeader.cmake#L234 should fix this.

Therre is a cmake test in qtbase, see https://github.com/bitwiseworks/qtbase-os2/tree/master/tests/auto/cmake/test(needsquoting)dirname. This test case among other things generates the following in one of the make files (a snippet):

ui_mywidget.h: D:/Coding/qt5/qt5/qtbase/tests/auto/cmake/test(needsquoting)dirname/mywidget.ui
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir="D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test(needsquoting)dirname/CMakeFiles" --progress-num=$(CMAKE_PROGRESS_1) "Generating ui_mywidget.h"
	D:/Coding/qt5/qt5-dev-build/qtbase/bin/uic.exe -o "D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test(needsquoting)dirname/ui_mywidget.h" "D:/Coding/qt5/qt5/qtbase/tests/auto/cmake/test(needsquoting)dirname/mywidget.ui"

moc_mywidget.cpp: D:/Coding/qt5/qt5/qtbase/tests/auto/cmake/test(needsquoting)dirname/mywidget.h
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold --progress-dir="D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test(needsquoting)dirname/CMakeFiles" --progress-num=$(CMAKE_PROGRESS_2) "Generating moc_mywidget.cpp"
	D:/Coding/qt5/qt5-dev-build/qtbase/bin/moc.exe "@D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test(needsquoting)dirname/moc_mywidget.cpp_parameters"

CMakeFiles/mywidget.dir/mywidget.cpp.o: CMakeFiles/mywidget.dir/flags.make
CMakeFiles/mywidget.dir/mywidget.cpp.o: CMakeFiles/mywidget.dir/includes_CXX.rsp
CMakeFiles/mywidget.dir/mywidget.cpp.o: D:/Coding/qt5/qt5/qtbase/tests/auto/cmake/test(needsquoting)dirname/mywidget.cpp
	@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir="D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test(needsquoting)dirname/CMakeFiles" --progress-num=$(CMAKE_PROGRESS_3) "Building CXX object CMakeFiles/mywidget.dir/mywidget.cpp.o"
	C:/USR/BIN/g++.exe  $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS) -o CMakeFiles/mywidget.dir/mywidget.cpp.o -c "D:/Coding/qt5/qt5/qtbase/tests/auto/cmake/test(needsquoting)dirname/mywidget.cpp"

an attempt to make this file with our kBuild make leads to this error:

make.exe: *** No rule to make target `needsquoting)dirname/mywidget.cpp)', needed by `CMakeFiles/mywidget.dir/mywidget.cpp.o'.  Stop.

The fun thing is that if I reorder some strings (in this particular case — move all the CMakeFiles/mywidget.dir/mywidget.cpp.o targets on top), the problem gets magically solved and the error goes away.

I have no idea what this error originates from but it might really be an issue of kBuild make. Might be extremely hard to find and fix, given make complexity, unless we are extremely lucky.

Found while working on bitwiseworks/qt5-os2#16.

For an EXE target named "none", the DEF file generated by cmake will look like this:

NAME none
DESCRIPTION "@#cmake build system:0.0#@##1## 05 Apr 2021 15:09:34     novator::::0::@@none"

This will result into the following wlink error:

weakld: D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test_import_plugins/none.def - error: Parse error 11 on line 1. (stmt=42)
weakld: error: Parse error 1 on line 11. (errorcode=42 stmt=7039341)
emxomfld: Invalid statement (line 1 of D:/Coding/qt5/qt5-dev-build/qtbase/tests/auto/cmake/build/test_import_plugins/none.def)

A fix is to put "none" in quotes as it seems to be a keyword or such and wlink barfs about that. This DEF works fine:

NAME "none"
DESCRIPTION "@#cmake build system:0.0#@##1## 05 Apr 2021 15:09:34     novator::::0::@@none"

A fix is to put this field in quotes then. Note that single quotes seems to also work fine.

The relevant commit introduced NAME to DEF is this: eb60524.

Found when working on bitwiseworks/qt5-os2#16.

Using cmake package 3.20.6-3.
Whenever I run cmake, it traps but nonetheless it finishes.

Attaching the POPUPLOG.OS2 entry:

`07-05-2023 08:17:51 SYS3170 PID 0049 TID 0001 Slot 0092
C:\USR\BIN\CMAKE.EXE
c0010001
1ffde411
EAX=00000000 EBX=000008dc ECX=0086fd4c EDX=00000003
ESI=2004c480 EDI=0000000c
DS=0053 DSACC=d0f3 DSLIM=3fffffff
ES=0053 ESACC=d0f3 ESLIM=3fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1f9595a1 CSACC=d0df CSLIM=3fffffff
SS:ESP=0053:0086fc98 SSACC=d0f3 SSLIM=3fffffff
EBP=0086fcb0 FLG=00010202

DOSCALL1.DLL 0003:0000e411`

Describe the bug
Using incorrect way of resolving environment variables.

To Reproduce

Expected behavior
https://cmake.org/cmake/help/latest/variable/ENV.html