classes/cmake: MSYS2 Windows support #32
Conversation
There was a problem hiding this comment.
I've had a quick glance over the changes.
I think we should first define what the AUTOCONF_ values are for the MSYS and Windows. They are the central information for all recipes and classes to judge on what platform is compiled (AUTOCONF_BUILD) and for which platform the executables/libraries are generated (AUTOCONF_HOST) (see autoconf documentation).
Quickly googling around lead me to *-*-mingw32 for native gcc builds and clang seems to use something like *-win32 for windows. It would be really good to enumerate the target triples. I think the CMake should make the decision about the "generator" based on this information. This decouples the toolchain and CMake class. Other build systems will face similar challenges so it makes sense to have a looser coupling between toolchain and cmake class.
Did you come up with *-pc-msys in plugins/multiarch.pyby yourself or is this already a standard somewhere?
classes/cmake.yaml
Outdated
| if [[ ${CMAKE_TOOLCHAIN_FILE:+true} ]] ; then | ||
| CMAKE_TOOLCHAIN_FILE="${BOB_TOOL_PATHS[target-toolchain]}/${CMAKE_TOOLCHAIN_FILE}" | ||
| else |
There was a problem hiding this comment.
I would rather not re-introduce this historic mistake. The toolchain itself should not bother about the build systems used downstream. If CMake needs a toolchain file then this should be handled by the CMake class. That's the same as for the meson class that also needs something similar.
There was a problem hiding this comment.
Okay. Understand, I'll fix this.
classes/cmake.yaml
Outdated
| buildScript: | | ||
| # Make sure CMake finds other stuff by its own logic too | ||
| CMAKE_FIND_ROOT_PATH= | ||
| for i in "${@:2}" ; do | ||
| # CMake needs win paths if we are in MSYS2 | ||
| [[ "$BOB_HOST_PLATFORM" == "msys" ]] && i="$(cygpath -m $i)" |
There was a problem hiding this comment.
Hmm, isn't that more dependent on the target platform / toolchain? It should still be possible to compile for msys2/mingw23/mingw64 which do not take windows paths I suppose.
There was a problem hiding this comment.
Ahh, correct, it doesn't depend directly on MSYS. It's the combination of MSYS and Windows. I have to use the CMAKE_GENERATOR variable. If we use Visual Studio, we are sure, that we are on Windows system. I guess the unix paths should work, if we build e.g. with Unix Makefiles generator.
classes/cmake.yaml
Outdated
| BUILD_SHARED_LIBS=ON | ||
| else | ||
| BUILD_SHARED_LIBS=OFF |
There was a problem hiding this comment.
Any reason why you removed this? The rationale is that all natively built libraries should be static because they are presumably used for host tools.
There was a problem hiding this comment.
What I missed here, is that the user can set the type manually inside the recipe.
making a library static or shared should not be limited by the system.
We need a mechanism to overwrite this. I'll add the handling, that ur defaults will be used, if the user havn't set this manually.
classes/install.yaml
Outdated
| # Install shared libraries only when cross compiling. On host builds only | ||
| # static libraries are installed. | ||
| if [[ "${AUTOCONF_BUILD:-unknown}" != "${AUTOCONF_HOST:-${AUTOCONF_BUILD:-unknown}}" ]]; then | ||
| INSTALL_SHARED=yes | ||
| fi | ||
|
|
There was a problem hiding this comment.
This basically breaks the whole basement Linux build. For host builds no shared libraries must be used because they lead to tools that cannot be executed at all or not reliably.
There was a problem hiding this comment.
I'll check how to merge, that the user could overwrite the library type.
classes/install.yaml
Outdated
| @@ -94,10 +88,10 @@ packageScript: | | |||
| { | |||
| installCopy "$@" /usr/ "/usr/include/***" \ | |||
| /usr/lib/ \ | |||
| "/usr/lib/*.a" \ | |||
| ${INSTALL_SHARED:+"/usr/lib/*.so*"} \ | |||
| "/usr/lib/***" \ | |||
There was a problem hiding this comment.
Now you install shared libraries even if they must not be installed.
classes/install.yaml
Outdated
| "/usr/lib/pkgconfig/***" \ | ||
| "/usr/lib/cmake/***" \ | ||
| /usr/bin/ "/usr/bin/***" \ |
There was a problem hiding this comment.
Why include /bin for -dev packages?
There was a problem hiding this comment.
cmake will add the lib and the dll in the -config.cmake file automatically. so if the dll is not there, this will break the build.
classes/install.yaml
Outdated
| /usr/lib/ "/usr/lib/*.so*" \ | ||
| /usr/bin/ "/usr/bin/*.dll" "/usr/bin/*.pdb" \ |
There was a problem hiding this comment.
installPackageLib should only install shared libraries. By removing *.so.* versioned libraries are broken.
There was a problem hiding this comment.
no idea, why i changed this lines handling so linux library files, doesn't depends to the windows cmake stuff. xD. I will revert this.
classes/install.yaml
Outdated
| installCopy "$@" /usr/ \ | ||
| /usr/bin/ "/usr/bin/***" \ | ||
| "!*" |
There was a problem hiding this comment.
What's the reason to change this? Now the function does not install anything except binaries. This will miss e.g. plugins, configuration files, ...
There was a problem hiding this comment.
I have to re-check this.
recipes/devel/cmake.yaml
Outdated
| win64: | ||
| buildVars: [PKG_VERSION] | ||
| buildScript: | | ||
| mkdir -p install/usr | ||
| rsync -aH --exclude 'doc/' --exclude 'man/' "$1/cmake-${PKG_VERSION}-win64-x64/" install/usr/ | ||
|
|
||
| packageScript: | | ||
| cp -a $1/install/* . |
There was a problem hiding this comment.
I think you should put this all into a separate recipes/devel/cmake-win64.yaml recipe. The windows CMake recipe has nothing in common with the regular one except the name 😆
There was a problem hiding this comment.
I just liked, that this was possible in this way. :D
But of course, creating a new recipe would have some advantages.
e.g. we can leave the BOB_HOST_PLATFORM stuff away.
I'll fix this.
classes/cmake.yaml
Outdated
| else | ||
| # windows does not support a sigle build type, we have to select the | ||
| # current type with cmake --build . --config | ||
| OPTIONS+=( -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE:-RelWithDebInfo} ) |
There was a problem hiding this comment.
Here I'll investigate again, I guess, I also could set the BUILD_TYPE to bob for Windows, if I added this configuration to CMAKE_CONFIGURATION_TYPES.
classes/cmake.yaml
Outdated
| ${INSTALL_OPTIONS:+"${INSTALL_OPTIONS[@]}"} | ||
| else | ||
| makeParallel $MAKE_TARGET ${MAKE_OPTIONS:+"${MAKE_OPTIONS[@]}"} |
There was a problem hiding this comment.
What do u think, could we use the cmake --build also for linux? In the end, cmake will call make also.
classes/cmake.yaml
Outdated
| # will be built again... | ||
| cmake --build . --parallel "${MAKE_JOBS-$(nproc)}" \ | ||
| --config ${CMAKE_BUILD_TYPE:-RelWithDebInfo} \ | ||
| --target $INSTALL_TARGET \ |
There was a problem hiding this comment.
Do we need a customizable install target? Will this ever used?
The cmake --install will call the default install target (cmake_install.cmake).
classes/cmake.yaml
Outdated
| fi | ||
| else | ||
| make $INSTALL_TARGET \ | ||
| DESTDIR=$DESTDIR \ |
There was a problem hiding this comment.
I will check, if that will change anything in Linux, if we use cmakes install_prefix instead of the DESTDIR of make.
|
yeah, we have to enumerate the triplets, here is how git for windows project is doing it: git-for-windows/msys2-runtime@6210daa |
thanks!
i am not sure about this. this
maybe it is a good idea to use the git solution. git is very common, and available for all worlds: git-for-windows/msys2-runtime@6210daa |
It's coming from autotools but they can and should be used elsewhere too. They are used as central switches to define the host and target environment. If all classes consistently use these variables then there is hopefully no need to have extra variables for the different build systems.
Yes, this looks promising. We just have to come up with some triples for VS builds. Maybe BTW, IIRC CMake finds the installed visual studio automatically, right? Or do you have a real Visual Studio toolchain recipe? I have the vague feeling that when building with VS the build results are dependent on the VS version, right? It would be good to have an example project that showcases the MSYS usage. Otherwise it's hard to tell if we're on the right track. |
We have to different between building with bob natively or in MSYS2 environment, havn't we?
here i invested some time. strange stuff IMO. if we use cmake without -G (generator string), than cmake detects automatically the newest MSVC. If there is a special requirement to the compiler version we have to set this. First: I guess we should JUST support Visual Studio 2019. VS2019 supports VS compiler versions of VS2015 and VS2017 by setting a toolset version. new since VS2019 is the following syntax: the system has completely changed since VS2019. now we can select older compiler versions of previous VS versions. CMAKE_GENERATOR: "Visual Studio 16 2019" --> FIX x64: 64 bit v140: VS2015 compiler version A problem. If we have a non-cmake module, like boost or qt4. Problem, it is not possible to load this environment variables in MSYS2, because the i am searching for a solution to get Another problem: the compiler itself inside the VS version can be updated by M$ VS-Installer. Next problem, just VS installation is just one part. the second part is the windows kit (sdk). next problem: if i load the example for vcvars: conclusion: windows and toolchains and env-vars is strange stuff. our current solution is the following: all developers in the company have to use the default installation paths. we use VS2019 professional. for the problem, that the compiler-version can be updated automatically by M$, we use a bob-class, which search for the "?" char, goes into the directory, and selects the highest number and replaces this with the "?". xD that we export the VS_* vars to MSYS2 without the VS_ |
|
Wow. This Windows stuff is so f***** insane. 😭 I have to think about it. Generally speaking the |
|
i found something very interesting. if i build boost with the b2 tool, the tool will generate a "msvc-setup.bat" file. UPDATE: i got it. create the following files: EDIT: |
|
This is a total mess. I have the feeling that the settings must be somehow gathered by a plugin which calls But CMake always seems to need its own settings. If it can't be done otherwise then we have to live with that. Interestingly the Visual Studio installation already comes with CMake. Meson and other seem to use the variables provided by |
|
yeah, but we need a way to source the |
|
I think we must spawn a cmd instance that calls vcvarsall and prints all variables. The output is then parsed by the plug-in. |
|
what do u think, should we implement this from the scratch by using we also need a mapping. b2 selects just compiler versions. 10.0 - 14.2.
depending which Visual Studio u have installed. EDIT: like i said:
|
I think it should be implemented without any unnecessary external dependencies. I was thinking about a plugin that executes a single batch file that does the following:
The plugin can then parse stdout and get all the variables we're interested in.
Yes. I think that's reasonable. Regarding the toolset version there still needs to be a special handling for CMake. All other build systems just use the environment variables. The |
|
plugin py-file: maybe we should make the interpreter class: Is there a way to minimize the logging-output if i'm using just optimized for MSYS2, will not work for native windows, maybe we should adapt this, too. the line with feedback welcome :) |
|
I've tested a bit and I don't think you have to convert the paths in your bash script. Just gather all variables in the plugin, cache them and query them one by one (not tested): import os, os.path
import subprocess
cache = {}
def vsvars(args, **options):
varname = args[0]
version = args[1]
platform = args[2:]
vswhere = os.path.join(os.environ["ProgramFiles(x86)"], "Microsoft Visual Studio/Installer/vswhere.exe")
tag = (version, tuple(platform))
if tag not in cache:
r = subprocess.check_output([vswhere, '-property', 'installationPath', '-products', '*',
'-requires', 'Microsoft.VisualStudio.Component.VC.Tools.x86.x64', '-version', version],
universal_newlines=True).strip()
r = subprocess.check_output([os.path.join(r, 'VC/Auxiliary/Build/vcvarsall.bat')] +
platform + ['&&', 'set'],
universal_newlines=True)
env = {}
for l in r.splitlines():
k,sep,v = l.strip().partition("=")
if k == 'PATH':
# convert to POSIX path to be mergeable
v = subprocess.check_output(["cygpath", "-u", "-p", v], universal_newlines=True).strip()
env[k] = v
cache[tag] = env
return env[varname]Then in the toolchain you can: environment:
"INCLUDE" : "$(vsvars,INCLUDE,'[16.0,17.0)',x64)"
"VS_PATH" : "$(vsvars,PATH,'[16.0,17.0)',x64)"The only thing that needs special care is I noticed that it takes quite a long time to fetch the variables. I think they should be cached somehow on disk. I'm just not sure what would invalidate them if the user updates, installs or removes toolsets. |
|
reviewed and tested. small issue: toolchain file: class to activate environment: important to bring to support more than vs2019, we just have to replace mapping:
just 1 more thing... could it a good idea, to give |
👍
Just a side note: while the usual target-toolchain:
path: "just_a_placeholder"
environment:
CMAKE_GENERATOR: "Visual Studio 16 2019"
...
No need to re-export variables unchanged. Also make sure to use quotes and append only if buildVars: [INCLUDE, LIB, LIBPATH, VS_PATH]
buildScript: |
${VS_PATH:+export PATH="$PATH:$VS_PATH"}
According to the Microsoft docs this path is valid for VS 2017 and 2019. Do we really have to support ancient versions too? I thought 2019 should be enough.
Not sure. I only installed the build tools and not the whole VS which should be enough to compile C/C++ code. For that you need the
No, I don't think this is a good idea. Maybe someone wants to specify a more specific version in the future? Better keep the flexibility. |
|
could we make the legacy-mode optionally?
With Visual Studio 2019 we can install compilers 2015 and newer... about the naming... would that be fine 4u? for the toolchain file, we could provide this multipackage: or we could handle it by toolchain environment variables: It's hard for me to select the best solutions. everything else look very nice, i would say. 👍 btw: how u bring color into the code-blocks :) |
|
I've just added a |
|
I added the plugin and the toolchain file in current version. That's all I have so far. |
|
👍 I'll hopefully look into it this evening. |
|
Ok, I've looked into it this weekend and could simplify it quite a bit. The VS-Generator is not necessary if the environment is setup correctly. The result is here: https://github.com/jkloetzke/basement/tree/feature/cmakeWindowsSupport I've added the test case to I also tried to get meson working but this does not seem to work at all. Meson does not work in an msys environment. It feels like we will have to add Python as 3rd language to Bob so that we can build true cross-platform recipes... |
What do u mean with VS-generator? [[ "$AUTOCONF_HOST" == *-win32 ]] && i="$(cygpath -m $i)"I guess, it should by *-win32)
CMAKE_SYSTEM_NAME=Windows
;;is The changes you made for calling cmake-configure, build and install, I do not understand :-/ the cpackage-class I do not understand so far. ... and is pkg-config supported for windows? and what is meson? never heard about that before, should i know it? |
The CMake "Visual Studio 16 2019" generator. This generator does some magic to find the toolchain itself. No other build system does that. But if the environment is setup correctly then the "Ninja" CMake generator can be used directly and CMake behaves like other build systems too.
No. We build for
You do in fact cross compile. Your build system, including Bob, runs on msys. This is a different ABI than what you are compiling for: win32 - native windows binaries without any msys dependency.
This is the common class for all c/c++ based packages. And no, pkg-config is not supported on Windows. 😀
This is just another build system that gains traction. It is like autotools and CMake. I used it as a litmus test to see if the changes go in the right direction, i.e. that they are general enough to cover not only CMake. Even if it is not a use case for you it should be possible to compile packages other than CMake too on Windows. But because meson and msys are not compatible it was deemed to fail... |
I build the Build result is in dev/dist/demo/linux+freertos/1/workspace
Which build-systems are supported in windows and MSYS. I just know CMake?! Meson supports Windows, but not MSYS2? What is the reason there - i guess it can just be an issue with the path-strings.
indeed. that is a point! i also seen that. if we build a project with boost (b2) and CMake, we saw, that both systems doesn't used the same information to find compiler a.s.o. CC=cl
CXX=cl
load the environmentworks for VS2019 compiler, but not for VS2015 compiler. there is an issue in the vcvarsall.bat files. the sdk 10.0 will not loaded fully, so rc.exe and mt.exe are missing. I love that windows stuff... |
This project does not use CMake. I've pushed an update for my branch that fixes the CMake class and cleans it further up. I still have to fix the meson build of the tests on Linux but it's going in a direction which I'm comfortable with. Please have a look.
Currently it's CMake but meson can be used on Windows too. Just not for msys directly.
Can't we just apply the workaround in the |
CMAKE_INSTALL_PREFIX="/usr"is there a reason, why my u doesn't used my solution: CMAKE_INSTALL_PREFIX="\/"the backslash prevents the converting to C:/msys64/usr and the usr is not necessary, refer here:
if we prefix the But, we have to make CMAKE_INSTALL_PREFIX variable. i would prefer: CMAKE_INSTALL_PREFIX="${CMAKE_INSTALL_PREFIX:-\/}"so a module, that doesn't support [[ "$AUTOCONF_HOST" == *-win32 ]] && i="$(cygpath -m $i)"what is with native windows? it will not support cygpath tool. shouldn't we check what is about this: -DCMAKE_PREFIX_PATH="/usr/lib/cmake;/usr"for find_package we use this CMake install path structure: DESTDIR="${PWD}/../install" cmake \
${INSTALL_COMPONENT:+-DCOMPONENT="$INSTALL_COMPONENT"} \
-P cmake_install.cmakewhy not using the common CMake way? if [[ -n "$INSTALL_TARGET" ]] ; then
if [[ "$INSTALL_TARGET" != "install" ]] ; then
COMPONENT="--component $INSTALL_TARGET"
fi
cmake --install . \
--config ${CMAKE_BUILD_TYPE:-Bob} \
--prefix ${CMAKE_INSTALL_PREFIX:-"../install"} \
${COMPONENT:+${COMPONENT}} \
${INSTALL_OPTIONS:+"${INSTALL_OPTIONS[@]}"}Ninja: have u tested the tests/msys? the self-built ninja wasn't used. for building Ninja we use Ninja. We need the bootstrap. diff --git a/recipes/devel/ninja.yaml b/recipes/devel/ninja.yaml
index a283d72..aa2e454 100644
--- a/recipes/devel/ninja.yaml
+++ b/recipes/devel/ninja.yaml
@@ -1,18 +1,23 @@
-inherit: [cmake]
+inherit: [cmake, patch]
metaEnvironment:
PKG_VERSION: "1.10.0"
checkoutSCM:
scm: url
- url: https://github.com/ninja-build/ninja/archive/v1.10.0.tar.gz
+ url: https://github.com/ninja-build/ninja/archive/v${PKG_VERSION}.tar.gz
digestSHA256: 3810318b08489435f8efc19c05525e80a993af5a55baa0dfeae0465a9d45f99f
- stripComponents: 1
+checkoutDeterministic: True
+checkoutScript: |
+ patchApplySeries $<<ninja/*.patch>>
+
+buildVars: [PKG_VERSION]
buildScript: |
- cmakeBuild -n "$1" # no install target!
+ cp -r $1/ninja-${PKG_VERSION}/* .
+ python configure.py --bootstrap
mkdir -p install/usr/bin
- cp build/ninja install/usr/bin/
+ cp ninja install/usr/bin/
packageScript: |
cmakePackageTgt
diff --git a/recipes/devel/ninja/0001-support-msys.patch b/recipes/devel/ninja/0001-support-msys.patch
new file mode 100644
index 0000000..16cf86a
--- /dev/null
+++ b/recipes/devel/ninja/0001-support-msys.patch
@@ -0,0 +1,130 @@
+--- workspace/ninja-1.10.0/configure.py 2020-01-27 11:37:35.000000000 +0100
++++ workspace/ninja-1.10.0/configure.py 2020-08-26 17:15:00.287544700 +0200
+@@ -64,6 +64,8 @@
+ self._platform = 'os400'
+ elif self._platform.startswith('dragonfly'):
+ self._platform = 'dragonfly'
++ elif self._platform.startswith('msys'):
++ self._platform = 'msvc'
+
+ @staticmethod
+ def known_platforms():
+@@ -83,8 +85,11 @@
+ def is_msvc(self):
+ return self._platform == 'msvc'
+
++ def is_msys():
++ return sys.platform.startswith('msys')
++
+ def msvc_needs_fs(self):
+- popen = subprocess.Popen(['cl', '/nologo', '/?'],
++ popen = subprocess.Popen(['cl', '-nologo', '-?'],
+ stdout=subprocess.PIPE,
+ stderr=subprocess.PIPE)
+ out, err = popen.communicate()
+@@ -142,9 +147,9 @@
+ return self.writer.newline()
+
+ def variable(self, key, val):
+- # In bootstrap mode, we have no ninja process to catch /showIncludes
++ # In bootstrap mode, we have no ninja process to catch -showIncludes
+ # output.
+- self.vars[key] = self._expand(val).replace('/showIncludes', '')
++ self.vars[key] = self._expand(val).replace('-showIncludes', '')
+ return self.writer.variable(key, val)
+
+ def rule(self, name, **kwargs):
+@@ -306,32 +311,32 @@
+ n.variable('ar', configure_env.get('AR', 'ar'))
+
+ if platform.is_msvc():
+- cflags = ['/showIncludes',
+- '/nologo', # Don't print startup banner.
+- '/Zi', # Create pdb with debug info.
+- '/W4', # Highest warning level.
+- '/WX', # Warnings as errors.
+- '/wd4530', '/wd4100', '/wd4706', '/wd4244',
+- '/wd4512', '/wd4800', '/wd4702', '/wd4819',
++ cflags = ['-showIncludes',
++ '-nologo', # Don't print startup banner.
++ '-Zi', # Create pdb with debug info.
++ '-W4', # Highest warning level.
++ '-WX', # Warnings as errors.
++ '-wd4530', '-wd4100', '-wd4706', '-wd4244',
++ '-wd4512', '-wd4800', '-wd4702', '-wd4819',
+ # Disable warnings about constant conditional expressions.
+- '/wd4127',
++ '-wd4127',
+ # Disable warnings about passing "this" during initialization.
+- '/wd4355',
++ '-wd4355',
+ # Disable warnings about ignored typedef in DbgHelp.h
+- '/wd4091',
+- '/GR-', # Disable RTTI.
++ '-wd4091',
++ '-GR-', # Disable RTTI.
+ # Disable size_t -> int truncation warning.
+ # We never have strings or arrays larger than 2**31.
+- '/wd4267',
+- '/DNOMINMAX', '/D_CRT_SECURE_NO_WARNINGS',
+- '/D_HAS_EXCEPTIONS=0',
+- '/DNINJA_PYTHON="%s"' % options.with_python]
++ '-wd4267',
++ '-DNOMINMAX', '-D_CRT_SECURE_NO_WARNINGS',
++ '-D_HAS_EXCEPTIONS=0',
++ '-DNINJA_PYTHON="%s"' % options.with_python]
+ if platform.msvc_needs_fs():
+- cflags.append('/FS')
+- ldflags = ['/DEBUG', '/libpath:$builddir']
++ cflags.append('-FS')
++ ldflags = ['-DEBUG', '-libpath:$builddir']
+ if not options.debug:
+- cflags += ['/Ox', '/DNDEBUG', '/GL']
+- ldflags += ['/LTCG', '/OPT:REF', '/OPT:ICF']
++ cflags += ['-Ox', '-DNDEBUG', '-GL']
++ ldflags += ['-LTCG', '-OPT:REF', '-OPT:ICF']
+ else:
+ cflags = ['-g', '-Wall', '-Wextra',
+ '-Wno-deprecated',
+@@ -419,9 +424,9 @@
+
+ if platform.is_msvc():
+ n.rule('cxx',
+- command='$cxx $cflags -c $in /Fo$out /Fd' + built('$pdb'),
++ command='$cxx $cflags -c $in -Fo$out -Fd' + built('$pdb'),
+ description='CXX $out',
+- deps='msvc' # /showIncludes is included in $cflags.
++ deps='msvc' # -showIncludes is included in $cflags.
+ )
+ else:
+ n.rule('cxx',
+@@ -433,7 +438,7 @@
+
+ if host.is_msvc():
+ n.rule('ar',
+- command='lib /nologo /ltcg /out:$out $in',
++ command='lib -nologo -ltcg -out:$out $in',
+ description='LIB $out')
+ elif host.is_mingw():
+ n.rule('ar',
+@@ -447,7 +452,7 @@
+
+ if platform.is_msvc():
+ n.rule('link',
+- command='$cxx $in $libs /nologo /link $ldflags /out:$out',
++ command='$cxx $in $libs -nologo -link $ldflags -out:$out',
+ description='LINK $out')
+ else:
+ n.rule('link',
+@@ -690,7 +695,10 @@
+ if platform.can_rebuild_in_place():
+ rebuild_args.append('./ninja')
+ else:
+- if platform.is_windows():
++ if platform.is_msys:
++ bootstrap_exe = './ninja.bootstrap.exe'
++ final_exe = './ninja.exe'
++ elif platform.is_windows():
+ bootstrap_exe = 'ninja.bootstrap.exe'
+ final_exe = 'ninja.exe'
+ else:this fix will not break windows build, i guess. |
|
there is another problem. against my hope... the vswhere.exe tool doesn't show the installation path of the VS compiler, it shows the path to the VS installation. so if i ask for version "[15.0,16.0)" i don't get the location of the vs2017 compiler, which was installed by VS2019. so my toolchain file is wrong, if we just want to support VS2019 installation with included compilers of vs2015, vs2017 and vs2019. the legacy mode is just to support older VS installations. the resulting problem: I have to call all the time the same vcvarsall.bat file. so how i can choose the compiler version without setting the cc, cxx = cl will always select ... hmm? maybe the newest vs2019 compiler? and just setting the SIDENOTE: cmake -G"Visual Studio 16 2019" -A x64 -T v140 ..\app
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.0.24245.0
-- The CXX compiler identification is MSVC 19.0.24245.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- workscmake -G"Visual Studio 16 2019" -A x64 -T v141 ..\app
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.16.27040.0
-- The CXX compiler identification is MSVC 19.16.27040.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe -- workscmake -G"Visual Studio 16 2019" -A x64 -T v142 ..\app
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.27.29111.0
-- The CXX compiler identification is MSVC 19.27.29111.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe -- workscmake -G"Visual Studio 16 2019" -A Win32 -T v140 ..\app
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.0.24245.0
-- The CXX compiler identification is MSVC 19.0.24245.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64_x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64_x86/cl.exe -- works--> this is Win32 (32-bit) it isn't necessary to load the funny, hmh? no idea how CMake extracts this information. |
|
conclusion: defaults:
- depends:
- name: devel::vs2019-toolchain
environment:
CMAKE_GENERATOR: <...>
CMAKE_GENERATOR_*: <...>
use|forward:<...> |
|
maybe u could live with that? diff --git a/classes/cmake.yaml b/classes/cmake.yaml
index 2516cac..0a81724 100644
--- a/classes/cmake.yaml
+++ b/classes/cmake.yaml
@@ -1,24 +1,18 @@
inherit: [cpackage, ninja, install]
buildTools: [cmake]
-buildVars: [AUTOCONF_HOST, CC, CXX, BUILD_SHARED_LIBS]
+buildVars: [CMAKE_GENERATOR, CMAKE_GENERATOR_PLATFORM, CMAKE_GENERATOR_TOOLSET,
+ CMAKE_INSTALL_PREFIX, CMAKE_BUILD_TYPE,
+ AUTOCONF_HOST, AUTOCONF_BUILD, CC, CXX, BUILD_SHARED_LIBS]
buildScript: |
# Make sure CMake finds other stuff by its own logic too
CMAKE_FIND_ROOT_PATH=
for i in "${@:2}" ; do
# CMake needs win paths if we are in MSYS2
- [[ "$AUTOCONF_HOST" == *-win32 ]] && i="$(cygpath -m $i)"
+ [[ "$AUTOCONF_BUILD" == *-msys ]] && i="$(cygpath -m $i)"
CMAKE_FIND_ROOT_PATH+="${CMAKE_FIND_ROOT_PATH:+;}$i"
done
- # This looks odd but it prevents MSYS from converting /usr to C:\msys64\usr
- # (or wherever MSYS was installed).
- if [[ "$AUTOCONF_HOST" == *-win32 ]] ; then
- CMAKE_INSTALL_PREFIX="C:/usr"
- else
- CMAKE_INSTALL_PREFIX="/usr"
- fi
-
# CMake does not honor CPPFLAGS! Merge them with C(XX)FLAGS.
if [ "${CPPFLAGS:+true}" ] ; then
CFLAGS+=" ${CPPFLAGS}"
@@ -96,22 +90,50 @@ buildScript: |
mkdir -p build install
pushd build
+ if [[ ${CMAKE_GENERATOR:-} == "Visual Studio"* ]] ; then
+ # since VS2019 we can select the platform and target by special variables
+ OPTIONS+=( ${CMAKE_GENERATOR_PLATFORM:+-A"${CMAKE_GENERATOR_PLATFORM}"} )
+ OPTIONS+=( ${CMAKE_GENERATOR_TOOLSET:+-T"${CMAKE_GENERATOR_TOOLSET}"} )
+ OPTIONS+=( -DCMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;RelWithDebInfo;MinSizeRel;Bob" )
+ else
+ # windows does not support a sigle build type, we have to select the
+ # current type with cmake --build . --config
+ OPTIONS+=( -DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE:-Bob} )
+ fi
+
+ # for find_package we use this cmake install path structure:
+ # <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
+ # this one is just supported for UNIX. For Windows we can use this:
+ # <prefix>/<name>*/ (W)
+ # by adding the CMAKE_PREFIX_PATH /usr/lib/cmake. For UNIX we add /usr.
cmake "$1" \
- -G Ninja \
+ -G"${CMAKE_GENERATOR:-Ninja}" \
${CMAKE_TOOLCHAIN_FILE:+-DCMAKE_TOOLCHAIN_FILE="$CMAKE_TOOLCHAIN_FILE"} \
-DCMAKE_FIND_ROOT_PATH="$CMAKE_FIND_ROOT_PATH" \
- -DCMAKE_BUILD_TYPE=Bob \
- -DCMAKE_INSTALL_PREFIX="$CMAKE_INSTALL_PREFIX" \
+ -DCMAKE_PREFIX_PATH="/usr/lib/cmake;/usr;/" \
+ -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX:-"\/"} \
-DBUILD_SHARED_LIBS=$BUILD_SHARED_LIBS \
+ ${OPTIONS:+"${OPTIONS[@]}"} \
"${@:2}"
- ninjaParallel ${MAKE_OPTIONS:+"${MAKE_OPTIONS[@]}"} \
- ${MAKE_TARGETS:+"${MAKE_TARGET[@]}"}
+ if [[ "${CMAKE_GENERATOR:-Ninja}" == "Ninja" ]] ; then
+ ninjaParallel ${MAKE_OPTIONS:+"${MAKE_OPTIONS[@]}"} \
+ ${MAKE_TARGETS:+"${MAKE_TARGET[@]}"}
+ else
+ cmake --build . --parallel "${MAKE_JOBS-$(nproc)}" \
+ --config ${CMAKE_BUILD_TYPE:-Bob} \
+ ${MAKE_TARGETS:+--target "${MAKE_TARGETS[@]}"} \
+ ${MAKE_OPTIONS:+"${MAKE_OPTIONS[@]}"}
+ fi
if [[ -n "$INSTALL" ]] ; then
- DESTDIR="${PWD}/../install" cmake \
- ${INSTALL_COMPONENT:+-DCOMPONENT="$INSTALL_COMPONENT"} \
- -P cmake_install.cmake
+ if [[ "$INSTALL_COMPONENT" != "install" ]] ; then
+ COMPONENT="--component $INSTALL_COMPONENT"
+ fi
+ cmake --install . \
+ --config ${CMAKE_BUILD_TYPE:-Bob} \
+ --prefix ${CMAKE_INSTALL_PREFIX:-"${PWD}/../install"} \
+ ${COMPONENT:+${COMPONENT}}
fi
popd
}
diff --git a/recipes/devel/vs2019-toolchain.yaml b/recipes/devel/vs2019-toolchain.yaml
index 4fe71ab..b633cb4 100644
--- a/recipes/devel/vs2019-toolchain.yaml
+++ b/recipes/devel/vs2019-toolchain.yaml
@@ -10,12 +10,20 @@ packageVars: [PLATFORM, VERSION]
packageScript: |
echo "$PLATFORM $VERSION" > version.txt
+privateEnvironment:
+ VERSION: "[16.0,17.0)"
+ PLATFORM: "x64"
+
provideTools:
target-toolchain:
path: "just_a_placeholder"
environment:
AUTOCONF_HOST: "x64_64-pc-win32"
+ CMAKE_GENERATOR: "${CMAKE_GENERATOR:-}"
+ CMAKE_GENERATOR_PLATFORM: "${CMAKE_GENERATOR_PLATFORM:-}"
+ CMAKE_GENERATOR_TOOLSET: "${CMAKE_GENERATOR_TOOLSET:-}"
+
INCLUDE: "$(vsvars,INCLUDE,${VERSION},${PLATFORM},${LEGACY:-False})"
LIBPATH: "$(vsvars,LIBPATH,${VERSION},${PLATFORM},${LEGACY:-False})"
LIB: "$(vsvars,LIB,${VERSION},${PLATFORM},${LEGACY:-False})"
@@ -28,42 +36,3 @@ provideTools:
CFLAGS: "-O$(if-then-else,$(eq,${BASEMENT_OPTIMIZE},0),d,${BASEMENT_OPTIMIZE})$(if-then-else,${BASEMENT_DEBUG}, -Zi,) -W3"
CXXFLAGS: "-O$(if-then-else,$(eq,${BASEMENT_OPTIMIZE},0),d,${BASEMENT_OPTIMIZE})$(if-then-else,${BASEMENT_DEBUG}, -Zi,) -W3"
LDFLAGS: ""
-
-multiPackage:
- vc140:
- privateEnvironment:
- VERSION: "[14.0,15.0)"
- LEGACY: "True"
-
- multiPackage:
- x64:
- privateEnvironment:
- PLATFORM: "x64"
- x86:
- privateEnvironment:
- PLATFORM: "x86"
-
- vc141:
- privateEnvironment:
- VERSION: "[15.0,16.0)"
- LEGACY: "True"
-
- multiPackage:
- x64:
- privateEnvironment:
- PLATFORM: "x64"
- x86:
- privateEnvironment:
- PLATFORM: "x86"
-
- vc142:
- privateEnvironment:
- VERSION: "[16.0,17.0)"
-
- multiPackage:
- x64:
- privateEnvironment:
- PLATFORM: "x64"
- x86:
- privateEnvironment:
- PLATFORM: "x86"
diff --git a/tests/linux/layers/self b/tests/linux/layers/self
index 1b20c9f..36dc815 120000
--- a/tests/linux/layers/self
+++ b/tests/linux/layers/self
@@ -1 +1 @@
-../../../
\ No newline at end of file
+../../../
diff --git a/tests/msys/recipes/cmake/greeter.yaml b/tests/msys/recipes/cmake/greeter.yaml
index ce05c1c..bce5a88 100644
--- a/tests/msys/recipes/cmake/greeter.yaml
+++ b/tests/msys/recipes/cmake/greeter.yaml
@@ -5,7 +5,7 @@ depends:
- name: devel::cmake-win64
use: [tools]
forward: True
- - name: devel::vs2019-toolchain-vc142-x64
+ - name: devel::vs2019-toolchain
use: [environment, tools]
forward: True
- cmake::libgreet-dev
diff --git a/tests/msys/recipes/meson/greeter.yaml b/tests/msys/recipes/meson/greeter.yaml
index 98bd4cd..f82c333 100644
--- a/tests/msys/recipes/meson/greeter.yaml
+++ b/tests/msys/recipes/meson/greeter.yaml
@@ -5,7 +5,7 @@ depends:
- name: devel::meson
use: [tools]
forward: True
- - name: devel::vs2019-toolchain-vc142-x64
+ - name: devel::vs2019-toolchain
use: [environment, tools]
forward: True
- meson::libgreet
diff --git a/tests/src/libgreet/CMakeLists.txt b/tests/src/libgreet/CMakeLists.txt
index 086a73d..fbd1862 100755
--- a/tests/src/libgreet/CMakeLists.txt
+++ b/tests/src/libgreet/CMakeLists.txt
@@ -54,7 +54,7 @@ configure_file(LibGreetConfig.cmake.in
COPYONLY
)
-set(ConfigPackageLocation lib/cmake/LibGreet)
+set(ConfigPackageLocation ${CMAKE_INSTALL_LIBDIR}/cmake/LibGreet)
install(EXPORT LibGreetTargets
FILE
LibGreetTargets.cmake
diff --git a/tests/src/libholler/CMakeLists.txt b/tests/src/libholler/CMakeLists.txt
index ae9b6a4..b71f294 100644
--- a/tests/src/libholler/CMakeLists.txt
+++ b/tests/src/libholler/CMakeLists.txt
@@ -48,7 +48,7 @@ configure_file(LibHollerConfig.cmake.in
COPYONLY
)
-set(ConfigPackageLocation lib/cmake/LibHoller)
+set(ConfigPackageLocation ${CMAKE_INSTALL_LIBDIR}/cmake/LibHoller)
install(EXPORT LibHollerTargets
FILE
LibHollerTargets.cmakenote: do not use static paths for cmake, ${CMAKE_INSTALL_LIBDIR} instead of lib. so cmake willl automatically prefix the /usr if necessary. |
xmake can also be obtained and used on windows/msys. |
To be honest: no. 😄 I don't want to treat CMake in any way special. And I still think it is not necessary. I've updated the vs2019-toolchain and the v141 and v142 toolchain versions do work here now. I didn't bother to test v140. I'm pretty sure it works too. I also added ninja to the I also moved the tools to
Why? Using a relative path will let CMake add the prefix. It compiles on Linux and Windows(msys) here. Why should we ever use |
|
first of all... wow. impressive performance 👍 just 3 small issues.. -AUTOCONF_HOST: "x64_64-pc-win32"
+AUTOCONF_HOST: "x86_64-pc-win32"and with the changes in the "rootrecipe", the "bob_example_embedded" has the issue now, that "host-toolchain" will be needed, but isn't available. for linux i guess the compat or sandbox-toolchain will do this?! again to the "/" vs "(C:)/usr" prefix: In my test, i used:
so the only cross-platform and working solution is the backslash-slash variant as far as i know:
one cool thing, it works for linux and windows. but now we also need the |
|
push. i am back from vacation :) |
|
I haven't looked too deeply into it. I have a number of changes pending that will collide with this PR. Once they have landed I will pick up here... |
When using ninja for cmake packages it would create a circular dependency on itself. Fortunately ninja can be bootstrapped without any external build tool.
Works like the make class. We use the Kitware fork of ninja that has the job server support integrated.
This changes the "cmakeBuild" options slightly. Should typically be faster than make, especially if nothing has changed.
Otherwise incremenatal builds will not prune stale files.
Always hide exported symbols because this is the default on Windows. Use appropriate export/import definitions instead. This temporarily breaks the meson build.
The CMake explample should build on Windows/MSYS too.
jkloetzke
force-pushed
the
feature/cmakeWindowsSupport
branch
from
02eb4c4
to
5441d5f
Compare
|
I've directly updated the pull request with the latest changes. I hope everything is addressed. Please test... |
|
hey! thanks for the great work. nearly everything looks very good in my tests. The only thing is the scenarion to use: But current result is It is also possible to use the why u want the yes, in case of otherwise a In the end it is up to you, that is just how I understood CMakes GNUInstallDirs. |
|
I think the "/usr" prefix should be kept on Linux builds. OTOH a prefix is somehow useless on Windows. In any case the prefix should be consistent throughout the project. If I understand correctly you only need to set I find it surprising that |
|
okay I'm fine! 👍 indeed, this works: but maybe we have not to set this inside the class. We could also set this manually inside the project, if necessary! |
|
soooo, when this will go live? :) |
|
The meson build of the example needs to be fixed and I have to test here if it breaks anything else. I hope somewhen next week... |
The GNUInstallDirs module does not handle the /etc case well. When using this standard module and doing an "install(FILES ... TYPE SYSCONF)" the result will end up in /usr/etc which is not correct. Set the CMAKE_INSTALL_SYSCONFDIR variable to the right absolute path instead.
Also introduce a -host and -cross multipackage to test the native and cross build case.
generally we could remove the dependency to the make-class, by using the cmake --build and cmake --install functionality also for linux. (but we would loose the DESTDIR feature, so we have to check --prefix and CMAKE_PREFIX_PATH stuff for linux)
feedback welcome!