Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy
After a quick test: pushing to gitlab.com fails as well :-(. The error does not seem to be related to kitware specific configuration. I think I'll abandon this approach an go for some NAS-based synchronization. -Ursprüngliche Nachricht- Von: Brad King Gesendet: Freitag, 29. März 2019 14:02 An: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Betreff: Re: AW: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy On 3/29/19 8:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > - pushing to kitware without 2FA fails > - pushing to kitware with 2FA fails Try using gitlab's own deployment on "gitlab.com". If that works then we can investigate differences. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy
Thanks for the hints so far, my current state is: - pushing to github works (yay!) - pushing to kitware without 2FA fails - pushing to kitware with 2FA fails - login with github credentials (on the website) works Does someone know if I can use github credentials for pushing, and how? Otherwise I will have to set up something with my NAS at home to sync from github to gitlab, because gitlab repo mirroring is only possible in push mode for gitlab community edition :-(. Anyway, I'll figure something out some day... -Ursprüngliche Nachricht- Von: Brad King Gesendet: Dienstag, 19. März 2019 13:42 An: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Betreff: Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy On 3/19/19 2:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > remote: HTTP Basic: Access denied > fatal: Authentication failed for > 'https://gitlab.kitware.com//cmake.git/' Try creating a personal access token to use during auth instead: * https://gitlab.kitware.com/help/user/profile/personal_access_tokens.md "You can also use them to authenticate against Git over HTTP. They are the only accepted method of authentication when you have Two-Factor Authentication (2FA) enabled." Otherwise, try using https auth from home without the proxy to make sure it works and narrow the cause. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy
Hello CMake developers, It's been some time now and I have tried everything that came into my mind (and I found on google), but I found no way to push any changes on my CMake fork. My situation: I am behind a corporate firewall which proxies/breaks all ssl connections and ssh is blocked completely. Using the following git configuration I am able to fetch/pull from kitware: [http "https://gitlab.kitware.com;] proxy = http://.com:8080 sslVerify = false Without the proxy configuration I am not able to connect to the repo, i.e. not even fetching is possible. With the proxy enabled I get request for username and password. After entering my credentials however I get the following message: Username for 'https://gitlab.kitware.com': Password for 'https://stuer...@gitlab.kitware.com': remote: HTTP Basic: Access denied fatal: Authentication failed for 'https://gitlab.kitware.com//cmake.git/' Can anyone help me so I can contribute to CMake again? This is really sad ... /Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)
This is weird: there is a test case called CSharpLinkToCxx which should cover the mentioned error. @rcdailey: could you check if this example works for you? best regards, Michael > -Ursprüngliche Nachricht- > Von: rcdai...@gmail.com [mailto:rcdai...@gmail.com] Im Auftrag von Robert > Dailey > Gesendet: Dienstag, 26. Juni 2018 17:34 > An: Brad King > Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Betreff: Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a > "vcxproj" (C++ project) > > I'm happy to do that. I assume you would require an MCVE for that bug? > If so it will take me considerably longer, as I don't have a lot of time to > build a > reproducible example from scratch. I'll do my best, though. > > On Tue, Jun 26, 2018 at 10:06 AM, Brad King > wrote: > > On 06/26/2018 10:25 AM, Robert Dailey wrote: > >> To fix this issue for now I had to do this: > >> > >> set_property( TARGET ${project_name} PROPERTY > LINKER_LANGUAGE > >> CSharp ) > >> > >> I don't remember having to explicitly tell CMake that the project is > >> CSharp in the past; it was always able to deduce it before. Is this > >> considered a symptom of a bug? Or is this required behavior? To be > >> honest, I'm not sure what criteria is used by CMake to deduce the > >> linker language of targets, especially in the C# case. It appears > >> that introducing a link-level dependency from a C# project to a > >> Managed C++ project, forces the parent project to be C++ as well. > > > > Please open an issue for that. > > > > Thanks, > > -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Unit testing CMake modules
Hello Wouter, testing CMake code is indeed very important. This is why kitware does it as well. Did you check the CMake code testing infrastructure in "Tests/RunCMake" in the sources? It is a very flexible concept which makes adding tests easy enough for everyone contribute (IMO). At the beginning it might be a bit confusing how expected results etc. are handled, but once you understand how it works it's really nice. Another (maybe the main) advantage: you have tons of examples and the RunCMake infrastructure is maintained so you don't have to it all on your own. best regards, Michael > -Ursprüngliche Nachricht- > Von: cmake-developers [mailto:cmake-developers-boun...@cmake.org] Im > Auftrag von Wouter Klouwen > Gesendet: Dienstag, 29. Mai 2018 18:36 > An: CMake Developers > Betreff: [cmake-developers] Unit testing CMake modules > > Hi all, > > We have a rather large amount of CMake code (4k+ lines) in various > modules/functions. They contain the common logic for many of our projects. > This makes it quite an important base for everything our team does. > > Rather shamefully at present these modules are rather poorly tested. I'd like > to improve this, but the current way of testing CMake code is typically to run > a trimmed project, and to verify whether certain invocations produce a > certain output or file hierarchy. > This involves a bit of infrastructure and can be a bit cumbersome maintain, to > diagnose when tests fail, and it requires a separate run of the tests. > The overall cumbersomeness of the setup in turn discourages in our team, > including myself, from adding tests. > > I'd like a more integrated approach that makes running at least some basic > tests part of the build progress, and a more direct way of reporting failures. > > In other programming environments, testing often involves some kind of > mocking environment, and CMake helpfully allows the overriding of CMake > built in functions, though this is typically discouraged. > > In my ideal world it would be possible to save the state of the current > function set up, then call a function with a certain given number of > parameters, and expect a certain sequence of events, such as functions to > be called, environment variables to be set, etc. > Something akin to CMakePushCheckState, except for built in functions. > > Then a module could provide for some functions that would set up > expectations and verify them, within a run of cmake, or possibly some other > commands could be added, to give some syntactic glossy coat to it. > > As it wouldn't actually trigger any of the expensive generating functions, it > would be lightweight, quick to run and give pretty direct errors in terms of > failed expectations, reducing debug time. > > If it was done with CMake commands, I might imagine it to look something > like: > > function(foobar) ># function to test, does something non trivial >if ("FOO" IN_LIST ARGV) > install(FILES foo DESTINATION foo_dir) >else("BAR" IN_LIST ARGV) > message(FATAL_ERROR "Some error") >else("BAZ" IN_LIST ARGV) > set(BAZ True PARENT_SCOPE) >endif() > endfunction() > > test(foobar) >expect(WITH "FOO" CALL install FILES foo DESTINATION foo_dir) >expect(WITH "BAR" CALL message FATAL_ERROR "Some error") >expect(WITH "BAZ" ENVIRONMENT BAZ True) > endtest(foobar) > > What do people think? Is this crazy? Is there a quicker way to get somewhere > close? Should I put some effort into making this into an actual > proposal/working code? > > Thanks in advance, > W > > > This transmission contains information that may be confidential and contain > personal views which are not necessarily those of YouView TV Ltd. YouView > TV Ltd (Co No:7308805) is a limited liability company registered in England > and > Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower > Thames Street, London, EC3R 6YT. For details see our web site at > http://www.youview.com > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting:
[cmake-developers] [SOLVED] CMake build with static crt and static QtDialog not linking
Hello Brad, I finally solved all remaining problems (there's only a cosmetic one left). Turns out there's a bug in the msvc 2017 compiler: https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html There is some discussion going on on the Qt side and a workaround for Qt is also available (though they don't want it in the master because it's a compiler and not a Qt issue): https://bugreports.qt.io/browse/QTBUG-56620 https://codereview.qt-project.org/#/c/207772/ For future reference I'd like to share my current solution of a Full-Static-Build of CMake: Toolchain: - Visual Studio 15.5.5 - Qt 5.10.1 Qt configure paramters: -platform win32-msvc2017 -opensource -confirm-license -static -static-runtime -mp -debug-and-release -nomake examples -nomake tests -nomake tools -no-gif -no-icu -no-pch -no-sql-sqlite -no-angle -no-opengl -no-dbus -no-qml-debug -no-harfbuzz -no-accessibility -skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdeclarative -skip qtdoc -skip qtgamepad -skip qtgraphicaleffects -skip qtimageformats -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip qtpurchasing -skip qtquickcontrols -skip qtquickcontrols2 -skip qtremoteobjects -skip qtscript -skip qtscxml -skip qtsensors -skip qtserialbus -skip qtserialport -skip qtspeech -skip qtsvg -skip qttranslations -skip qtvirtualkeyboard -skip qtwayland -skip qtwebchannel -skip qtwebengine -skip qtwebglplugin -skip qtwebsockets -skip qtwebview -skip qtwinextras -skip qtx11extras -skip qtxmlpatterns -no-feature-testlib -no-feature-sql-odbc -no-feature-style-fusion -feature-style-windowsvista -feature-style-windows -feature-directwrite -feature-direct2d -feature-sql -feature-network -qt-pcre -qt-zlib -qt-libjpeg -qt-libpng CMake configuration: 1) Qt static link additional libs: set QT_S_LIB="%QT_BASE_DIR%/lib/qtpcre2$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/lib/qtlibpng$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/lib/qtfreetype$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/lib/Qt5FontDatabaseSupport$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/lib/Qt5ThemeSupport$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/lib/Qt5EventDispatcherSupport$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/plugins/platforms/qwindows$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;"%QT_BASE_DIR%/plugins/styles/qwindowsvistastyle$<$:d>.lib" set QT_S_LIB=%QT_S_LIB%;imm32.lib;version.lib;netapi32.lib;uxtheme.lib;dwmapi.lib 2) configure command: "%CMAKE_CMAKE_COMMAND%" ^ -G "Visual Studio 15" -A x64 -T v141,host=x64 ^ -D CMAKE_INSTALL_PREFIX:STRING="%CMAKE_INSTALL_PREFIX%" ^ -D BUILD_QtDialog:BOOL=ON ^ -D QT_QMAKE_EXECUTABLE:FILEPATH=%QT_BASE_DIR%/bin/qmake.exe ^ -D Qt5Widgets_DIR:PATH=%QT_BASE_DIR%/lib/cmake/Qt5Widgets ^ -D BUILD_DOCUMENTATION:BOOL=ON ^ -D CMAKE_USE_OPENSSL:BOOL=OFF ^ -D CMAKE_C_FLAGS_RELEASE:STRING="/MT /O2 /Ob2 /DNDEBUG" ^ -D CMAKE_CXX_FLAGS_RELEASE:STRING="/MT /O2 /Ob2 /DNDEBUG" ^ -D CMAKE_C_FLAGS_DEBUG:STRING="/MTd /Zi /Ob0 /Od /RTC1" ^ -D CMAKE_CXX_FLAGS_DEBUG:STRING="/MTd /Zi /Ob0 /Od /RTC1" ^ -D CMAKE_C_FLAGS_MINSIZEREL:STRING="/MT /O1 /Ob1 /DNDEBUG" ^ -D CMAKE_CXX_FLAGS_MINSIZEREL:STRING="/MT /O1 /Ob1 /DNDEBUG" ^ -D CMAKE_C_FLAGS_RELWITHDEBINFO:STRING="/MT /Zi /O2 /Ob1 /DNDEBUG" ^ -D CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING="/MT /Zi /O2 /Ob1 /DNDEBUG" ^ -D SPHINX_HTML:BOOL=ON ^ -D CMake_QT_STATIC_QWindowsIntegrationPlugin_LIBRARIES:STRING="!QT_S_LIB!" ^ "%CMAKE_SOURCE_DIR%" Qt patch to fix compiler error: https://codereview.qt-project.org/#/c/207772/ Maybe this helps someone else trying to do a full static build of CMake for Windows. Best regards, Michael > -Ursprüngliche Nachricht- > Von: cmake-developers [mailto:cmake-developers-boun...@cmake.org] Im > Auftrag von Stuermer, Michael SP/HZA-ZSEP > Gesendet: Freitag, 16. Februar 2018 16:23 > An: Brad King > Cc: cmake-developers@cmake.org > Betreff: Re: [cmake-developers] CMake build with static crt and static > QtDialog not linking > > > > > On 2/16/2018 7:43 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > 1) The debug version crashes in > > > > I don't know if we've ever built a debug configuration against this Qt. > > > > > This application failed to start because it could not find or load > > > the Qt platform plugin "windows" in "". > > > > We statically link that plugin. See our release build settings here: > > > > https://gitlab.kitware.com/cma
Re: [cmake-developers] CMake build with static crt and static QtDialog not linking
> > On 2/16/2018 7:43 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > 1) The debug version crashes in > > I don't know if we've ever built a debug configuration against this Qt. > > > This application failed to start because it could not find or load the > > Qt platform plugin "windows" in "". > > We statically link that plugin. See our release build settings here: > > https://gitlab.kitware.com/cmake/cmake/blob/v3.11.0- > rc1/Utilities/Release/win64_release.cmake > Thanks for this hint, now it crashes in debug when loading the plugin, but it works well for release. So I guess it's fine for now. I'll investigate this a bit further and come back here if I find some solutions for the debug crashes or get later Qt versions working as well. > In particular, CMake_QT_STATIC_QWindowsIntegrationPlugin_LIBRARIES > in the initial cache file configures use of the static plugin. > > > @brad: could you please provide a config.summary from the kitware Qt- > build? > > Maybe I need to change the windows sdk version or so to fix my problem. > > We use a custom environment to use the VS 2017 toolchain but still support > Windows XP: > > ``` > Environment: > INCLUDE= > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\include > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\atlmfc\include > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt > c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\include > LIB= > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\atlmfc\lib\x64 > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\lib\x64 > C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64 > c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\lib\x64 > PATH= > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64 > C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64 > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\MSBuild\15.0\bin > C:\Windows\Microsoft.NET\Framework64\v4.0.30319 > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\Common7\IDE > C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\Common7\Tools > C:\Windows\system32 > C:\Windows > Configuration: > pcre > release > compile_examples > msvc_mp > Qt Configuration: > minimal-config > small-config > medium-config > large-config > full-config > release > static > static_runtime > zlib > no-gif > jpeg > png > freetype > audio-backend > no-qml-debug > directwrite > native-gestures > qpa > concurrent > > QMAKESPEC...win32-msvc2017 (commandline) > Architecturex86_64, features: sse sse2 Host > Architecture...x86_64, features: sse sse2 > Maketoolnmake > Debug...no Force debug infono > C++ language standard...auto > Link Time Code Generation...no > Using PCH ..no > Accessibility support...no > RTTI supportyes > SSE2 supportyes > SSE3 supportyes > SSSE3 support...yes > SSE4.1 support..yes > SSE4.2 support..yes > AVX support.yes > AVX2 supportyes > NEON supportno > OpenGL support..no > Large File support..yes > NIS support.no > Iconv support...no > Evdev support...no > Mtdev support...no > Inotify support.no > eventfd(7) support..no > Glib supportno > CUPS supportno > OpenVG support..no > SSL support.no > OpenSSL support.no > libproxy supportno > Qt D-Bus supportno > Qt Widgets module support...yes > Qt GUI module support...yes > QML debugging...no > DirectWrite support.yes > Use system proxies..no > > QPA Backends: > GDI.yes > Direct2Dno > > Third Party Libraries: > ZLIB supportqt > GIF support.no > JPEG supportyes > PNG support.yes > FreeType supportyes &g
Re: [cmake-developers] CMake build with static crt and static QtDialog not linking
Hello Brad and thank you for your hints! To get everything working I decided to switch to the same Qt version for now and mimic the kitware-build: - Visual Studio: 2017 (15.5.5) - Qt 5.6.3 1) The debug version crashes in Source/QtDialog/FirstConfigure.cxx:566 when initializing a const QString. The actual error occurs in QArrayData::deallocate() when ::free() is called. No idea so far what this means. 2) The release version seems to skip the debug error but complains with the message: >>This application failed to start because it could not find or load the Qt >>platform plugin "windows" in "".<< Does anyone know how I can fix this? So far I always only built Qt but never really hacked/fixed anything. I enclose my qtbase/config.summary file for reference. @brad: could you please provide a config.summary from the kitware Qt-build? Maybe I need to change the windows sdk version or so to fix my problem. What I checked so far: a) The DLL-Dependencies as shown in the Dependency Walker are identical, only IMM32.DLL is missing in my binary. So I think this should be OK. b) I'm doing a temporary hack in QtDialog CMakeLists.txt at the moment to link to qtpcre: set(qt_base_dir "X:/Qt/qt5.6.3Install") set(qt_lib_dir "${qt_base_dir}/lib") target_link_libraries(cmake-gui "${qt_lib_dir}/qtpcre$<$:d>.lib") Bad but I allows to rebuild/reinstall Qt without having to modify the install directory afterwards. -Ursprüngliche Nachricht- Von: Brad King [mailto:brad.k...@kitware.com] Gesendet: Dienstag, 13. Februar 2018 18:11 An: Stuermer, Michael SP/HZA-ZSEP Cc: cmake-developers@cmake.org Betreff: Re: [cmake-developers] CMake build with static crt and static QtDialog not linking On 2/13/2018 11:28 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > I try to do a CMake build with static C runtime and a static Qt 5.10.0 Make sure Qt is configured with both `-static` and `-static-runtime`, and that it is built with the same compiler as CMake. See the command used below to configure the 64-bit Qt build for the cmake.org binaries. We use Qt 5.6.3 because it is the last to support Windows XP. Also, Qt 5.6 doesn't quite set up it's CMake targets correctly when doing a static build. I had to hack lib/cmake/Qt5Core/Qt5CoreConfig.cmake: set(_Qt5Core_LIB_DEPENDENCIES "${_qt5Core_install_prefix}/lib/qtpcre.lib") > PS: I'm not sure how the mailing list is handled compared to the > gitlab instance. Would this be something I should open an issue for? The mailing list is fine for this. -Brad ``` call ..\qt-everywhere-opensource-src-5.6.3\configure.bat ^ -prefix c:/path/to/prefix ^ -static ^ -static-runtime ^ -release ^ -opensource -confirm-license ^ -platform win32-msvc2017 ^ -mp ^ -gui ^ -widgets ^ -qt-pcre ^ -qt-zlib ^ -qt-libpng ^ -qt-libjpeg ^ -no-gif ^ -no-icu ^ -no-pch ^ -no-sql-sqlite ^ -no-cetest ^ -no-angle ^ -no-opengl ^ -no-dbus ^ -no-qml-debug ^ -no-harfbuzz ^ -no-accessibility ^ -skip declarative ^ -skip multimedia ^ -skip qtcanvas3d ^ -skip qtconnectivity ^ -skip qtdeclarative ^ -skip qtlocation ^ -skip qtmultimedia ^ -skip qtsensors ^ -skip qtserialport ^ -skip qtsvg ^ -skip qtwayland ^ -skip qtwebchannel ^ -skip qtwebengine ^ -skip qtwebsockets ^ -skip qtwinextras ^ -skip qtxmlpatterns ^ -nomake examples -nomake tests ``` config.summary Description: config.summary -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] CMake build with static crt and static QtDialog not linking
I try to do a CMake build with static C runtime and a static Qt 5.10.0 build to avoid runtime errors when giving the binaries to colleagues. The Visual Studio version is 2017. AFAIK the official CMake builds already use this "full-static-build" scheme. However I end up with some linking errors of 137 unresolved external symbols starting with unresolved external symbol __imp_OpenThemeData referenced in function "public: virtual void __cdecl QVistaBackButton::paintEvent and ending with unresolved external symbol NetApiBufferFree referenced in function "public: static bool __cdecl QFileSystemEngine::uncListSharesOnServer Are there some tricks I have to do to get this working? I changed all /MD flags manually to /MT, but nothing else so far. PS: I'm not sure how the mailing list is handled compared to the gitlab instance. Would this be something I should open an issue for? I personally do not see it as an issue (which means "something has to be changed in the code" for me). Or is the mailing list more or less a leftover from before-gitlab times? Best regards, Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] GitLab speed
>From my side access to the web interface as well as repo handling is also >slower than github. I personally consider this more to be a luxury problem >than a real issue. Would be great if were faster but it works well for me. On >the other hand I like the whole workflow, that is great! I suppose the whole repo infrastructure is hosted at kitware and the bandwidth to the internet is just limited at some point. > -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Harry Mallon > Sent: Tuesday, November 29, 2016 11:02 AM > To: cmake-developers@cmake.org > Cc: Harry Mallon > Subject: Re: [cmake-developers] GitLab speed > > Hi Brad, > > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT E ha...@codexdigital.com | T > +44 203 7000 989 > > On 28 Nov 2016, at 20:01, Brad Kingwrote: > > > > On 11/28/2016 02:27 PM, Harry Mallon wrote: > >> moving around the interface and even pushing to repos seems to be > >> much slower than the equivalent thing on github. > > > > Has it only been today or the last few days that you've noticed this? > > It does feel slower today than usual. I'll check with our admins. > > I am not sure of the answer to this. I have only just moved over to prepare a > tiny merge request. > > > > >> I am not sure whether this report is constructive > > > > It is legitimate feedback presented in a civil tone. > > > > Thanks, > > -Brad > > > > Harry > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] gitlab or github? Which should I use for contribution?
> -Original Message- > From: Brad King [mailto:brad.k...@kitware.com] > Sent: Wednesday, October 26, 2016 5:13 PM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] gitlab or github? Which should I use for > contribution? > > On 10/26/2016 10:05 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Which should I choose for future contributions? > > GitLab, please. We recently updated CONTRIBUTING.rst to prefer it even > over patches on this list. > > > My feeling is I could completely abandon the github repository and > > pull and push only to gitlab.kitware.com. > > Yes. > > > I can't see all the other branches like maint, next, nightly-* etc. > > on the gitlab repo. Still these branches get regularly updated on > > github. This makes me feel like the gitlab repo is somehow "incomplete". > > The `maint` branch has not proven useful and may be dropped one day. > The `next` and `nightly` branches are only for the nightly testing > infrastructure and not something developers need to use. > > The GitHub repo is just a mirror of the cmake.org repo and has always had > the extra branches and so still does. The GitLab repo is where we are trying > to move development so we're populating it only with the branches needed > by developers. > > -Brad > . thanks for the information, exactly what I needed! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] gitlab or github? Which should I use for contribution?
I know the cmake repositories on github and gitlab are in sync, so I could base my work on any of them. Still I don't want to maintain two forks and would prefer to switch completely to gitlab.kitware instead. Which should I choose for future contributions? My feeling is I could completely abandon the github repository and pull and push only to gitlab.kitware.com. All merge requests are handled there anyway. Is this right? I can't see all the other branches like maint, next, nightly-* etc. on the gitlab repo. Still these branches get regularly updated on github. This makes me feel like the gitlab repo is somehow "incomplete". Is there some kind of a distinction between "official" and "development" repository? I'm just trying to understand . Viele Grüße Michael Stürmer SZ. Prozessdatenverarbeitung SP/HZA-ZSEP Tel. +499132 82-86350 Mobil.: +49(171)6860010 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] preparations for native C# support
These are some minor changes for native support of C# targets. The remaining C++ implementation will go into the Visual Studio target 10 generator class. Best Regards Michael Stürmer 0001-preparational-patches-for-CSharp-support.patch Description: 0001-preparational-patches-for-CSharp-support.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Native C# support in CMake
Hi, check this out, might help: https://github.com/micst/CMake.git There is a working C# implementation available. I permanently try to keep it up-to-date with master and mergable so the workload will not become too large as soon as I find time to prepare patches for upstream. Contribution (especially about finding C# compilers and .NET frameworks and setting necessary variables) is always welcome. Search the mailing list about status and open issues, there’s still quite something to do... best regards, Michael From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Andreas Roth Sent: Monday, September 12, 2016 1:23 PM To: cmake-developers@cmake.org Subject: [cmake-developers] Native C# support in CMake Hi, i was wondering if you plan to support C# as language. Currently we are using a custom tailored set of command lines for building but it becomes more and more difficult when complexer requirements surface. Regards, Andreas Roth Development Engineer FAST Protect GmbH Siemensstrasse 16/1 88048 Friedrichshafen Germany . -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, September 09, 2016 8:33 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Here it is. > > > > The patch only seems to allow patching Features generated for components > but not Features generated for component groups. > Is that intentional or an oversight? > > I think we should allow patching for both. > > Nils > The details you miss if you are not using the features ... thanks for the hint, here is corrected patch. Michael 0001-enabled-patching-of-WIX-Feature-tags.patch Description: 0001-enabled-patching-of-WIX-Feature-tags.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PATCH: Bugfix for WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 4:28 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: Bugfix for WIX support > > On 09/06/2016 03:45 PM, Nils Gladitz wrote: > > > > > > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf > 10d99ff9b3d8f68919164fcf8 > > > > > > Please verify that I haven't broken anything. > > I broke writing of WIX include files. Should be fixed now: > https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=19f96b8bd54a6d > c9c4c08ba90250c3a7ae013227 > > Nils I checked everything on our project. Works as expected so far. I had to add our CSharp patch(es) on top, so this is not a pure WIX feature test, but I think it's good to go. Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 3:50 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated .wxs sources > > On 09/06/2016 03:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > > > Hm, I don't see how I can add a namespace before my patch fragment. If I > want to use some element from let's say UtilExtension, I need to add the > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension; attribute in > some parent XML node as far as I understand (no XML expert though). > > You only have to declare the namespace on the element itself. There is no > need for the parent to have it declared. > Every day you learn something new, good. This feels a bit strange, but it works! Obviously the patch is not necessary. > So unless you object for other reasons I don't think the patch is necessary? > > Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources
Wow, thanks for the fast answer! > -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 2:29 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated .wxs sources > > On 09/06/2016 01:32 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > best regards, > > Michael > > Can you elaborate your use case for the patch? > > I assume this if for custom patch fragments? > In that context wouldn't it suffice to add the namespace declarations to the > elements that need them (in the patch fragment itself)? > Hm, I don't see how I can add a namespace before my patch fragment. If I want to use some element from let's say UtilExtension, I need to add the xmlns:util="http://schemas.microsoft.com/wix/UtilExtension; attribute in some parent XML node as far as I understand (no XML expert though). When patching an element, I cannot set attributes within the actual parent node I am patching. For now I managed to move all usages of additional namespace to custom WIX sources, so I do not depend on this patch anymore. Nevertheless I believe it's a good thing being able to influence the used namespaces. > The patch is also missing documentation for the new > CPACK_WIX_NAMESPACES variable that it introduces. > Oh, right. Sorry. I will provide it (if the change will be accepted). > Thanks. > > Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources
best regards, Michael 0002-added-support-for-custom-WIX-namespaces-in-generated.patch Description: 0002-added-support-for-custom-WIX-namespaces-in-generated.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] PATCH: Bugfix for WIX support
The generated guid values where not set correctly everywhere. This could lead to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option. Viele Grüße Michael Stürmer SZ. Prozessdatenverarbeitung SP/HZA-ZSEP Tel. +499132 82-86350 Mobil.: +49(171)6860010 0001-fixed-setting-of-invalid-guids-in-WIX-source-files-i.patch Description: 0001-fixed-setting-of-invalid-guids-in-WIX-source-files-i.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, August 16, 2016 10:54 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 08/16/2016 10:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > > > After having look at the code for some minutes I remember why patching > the ref instead oft he feature was my way to go: > > > > The feature is written to file in > cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not > have any patch information available. This means I'd have to change the > signature of both EmitFeatureForComponent and > EmitFeatureForComponentGroup and pass a reference to the patch instance > along. Multiple occurrence of IDs can happen, but the patch will only be > applied once because applied fragments are erased immediately after > writing them to the stream. > > > > So after all for me this was a consideration of a 1-line change vs. changing > class interfaces an passing object instances to where it might not be > desirable. > > There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I > think such an interface change would be fine. > Ok I'll do this. Should solve all issues and doubts hopefully. > > > > I agree the commit message of the patch is not accurate enough and if > there is way to add custom WIX-components to features without changing > the cpack source I'd be happy to do so. But so far I tried several approaches > and neither worked (see below). > > > >> This would not be any more convenient but would certainly match > >> expectations and be less ill defined. > >> e.g. when I specify a patch for a Feature I expect that the Feature > >> with the given ID gets patched. > >> > >> Arguments against patching a FeatureRef instead are: > >> - There can be n FeatureRef elements for any Feature element in which > >> case it would not be obvious if the patch should be applied to one > >> (which?) or all of these > > The way the patch was implemented only the featurerefs in the generated > features.wxs file would be patched and there should not be any double > occurences of a feature ref. > > > >> - While similar FeatureRef and Feature don't take the same Child > >> elements > > Right, and if both Feature and FeatureRef would be patchable we would be > in trouble. For the lazy one: this is not the case at the moment so we would > not need to worry about it (but it's very nice). For the correct one: We could ... meant NOT very nice, of course ... > introduce another attribute to CPackWixFragment called "Type" where type > of the XML node to be patched could be stored. But this would introduce > additional complexity to the cmWIXPatch class... > > There is no use case to be able to patch both FeatureRef and Feature > elements when Feature elements can be patched directly. > Right. > > > >> - You can already define your own FeatureRef elements (referencing > >> any of the pre-existing Feature elements if wanted) without having to > >> use the patch mechanism > >> > > I tried this like this (in a separate additional .wxs source file added with > CPACK_WIX_EXTRA_SOURCES): > > > > http://schemas.microsoft.com/wix/2006/wi;> > > > > Directory="INSTALL_ROOT"> > > > > > > > > > > IgnoreParent="yes"> > > > > > > > > > > > > Did not work, the registry value was not set. Using the proposed approach > it worked. Do I have to reference it somehow different? > > The linker only includes object files which provide a symbol that is required > by an object already included. > Your source file has a single symbol for the Component "SetRegistryValues" > but that symbol (I assume) is not required by any of the other objects which > the linker includes. > > You could e.g. add the FeatureRef to a custom WIX.template.in (which has > the main entry point and is therefor always included), or supply a patch for > the Product element (#PRODUCT), or create any kind of valid reference to > your custom source file (if any reference is resolved through your custom > source the entire object gets included). > Adding FeatureRef to #PRODUCT does not work. I get the following message: features.wixobj : error LGHT0095 : Multiple primary references were found for Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}' > Nils > . Michael -- Powered by www.kitware.
Re: [cmake-developers] [Patch 5/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Friday, August 12, 2016 9:42 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > best regrads, > > Michael > > > > Patch 5 seems to implement patching of FeatureRef rather than the original > Feature elements. > I am not sure if this is what you intended but this could be error prone given > that there could in theory be any number (0-n) FeatureRef elements for any > corresponding Feature element. > > Nils The intention was to be able to add custom components that are added as extra .wxs source files to certain features. If there are more convenient ways to do this I will be happy to change the implementation or adapt my WIX project. But so far this seemed to be a very easy and intuitive solution: the additional component references are added in the same place where all other component references are added as well. Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 3/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, August 02, 2016 10:47 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > best regrads, > > Michael > > Patch 3 looks OK but I think I would prefer using WiX over CPack > nomenclature in the variables you introduce. > > e.g. > > CPACK_WIX_ROOT_FEATURE_TITLE and > CPACK_WIX_ROOT_FEATURE_DESCRIPTION > > over > > CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and > CPACK_WIX_ROOT_COMPONENT_DESCRIPTION > > given that CPack has no concept of a root component. > > Would you agree? > totally. > Nils Best Regards Michael Stürmer -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# with CMake
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Dennis Luehring > Sent: Friday, July 22, 2016 6:38 AM > To: cmake-developers@cmake.org > Subject: [cmake-developers] C# with CMake > > any status update for the CMake C# Generator? > > read thorugh "C# support ready for review" > https://cmake.org/pipermail/cmake-developers/2016-March/027911.html > > seem to be still active: > https://github.com/micst/CMake/tree/csharp > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers unfortunately not. I try to keep my fork up to date with kitwares master for easy merging, but I don't have time for more right now. The main part missing (hopefully) is a proper compiler detection as mentioned by Brad: https://cmake.org/pipermail/cmake-developers/2016-March/027945.html Help in implementing proper compiler detection would be greatly appreciated, I will continue on this as soon as I can (but it can be months until then). Best Regards Michael Stürmer -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 1/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Thursday, July 21, 2016 8:56 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 1/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > To start with I don't think I really like the first patch as it is. > > We should either require that install file locations are canonical (which is > what > I went for when I initially implemented them; I think I would still prefer it > that > way), or perform more complete and consistent canonicalization. e.g. > > - The implementation as-is only works with cmake's internal path separation > (forward slash). > Given the canonical path "foo/bar" the path "foo\bar" does not currently > work. So neither should a backslash work in a prefix e.g. > ".\foo/bar". > I'd also like to think of these paths as portable (should any other CPack > generator choose to implement install properties as well) which is why I think > we should not support (canonicalize) windows path separators anywhere in > the path. > > - Handling "." only as a singular prefix is inconsistent. > If we do implement this then ".." should also be supported and > canonicalization should work anywhere in the path. > e.g. given the canonical path "foo/bar/baz" these should refer to the > same > path: > - "./foo/bar/baz" > - "././foo/bar/baz" > - "foo/./bar/baz" > - "foo/../foo/bar/baz" > etc. > > Nils Thanks for the detailed feedback! Proper canonicalization when setting up the map of installed files is a better way to go. I just had the impression the key of the file in the map ("./foo", "foo", ...) should not be changed. If this is not the case and we can change/improve the canonicalization where the installed files are set up we can discard this patch and I'll have a look at it again in the future. For my current task I do not need the install properties anymore, so there is no dependency to this patch from the others. Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Wednesday, July 20, 2016 12:03 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] Improved WIX support > > On 19.07.2016 17:43, Stuermer, Michael SP/HZA-ZSEP wrote: > > Hello there, > > > > in short: > > > > I fixed some minor issues with WIX toolset support and added the > possibility to integrate service installation/uninstallation with generated > msi > packages. Please review and comment what is missing for integration in > upstream. > > > > a bit longer: > > > > When creating a component-based installer, the root component (or > feature, as it is called in WIX context) cannot be named and described. This > can now be done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME > and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION. > > > > The install folder can only be set to a subfolder of ProgramFiles or > ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it is > now possible to set default installation paths on arbitrary locations such as > "C:\myprogram". In order for this to work, the Guids of the WIX- > Components must be explicitly set using > CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are > auto generated using the value "*". > > > > Disabling components by default using the > CPACK_COMPONENT__DISABLED is now working. > > > > With the install file properties CPACK_WIX_KEYPATH and > CPACK_WIX_PROPERTY_ it is now possible to add custom tags > (such as service handling) to the installer. If the custom tag depends on > several files within the directory, bundling of several files in WIX- > Components is needed. This can be done using > CPACK_WIX_BUNDLE_COMPONENTS. > > > > All new functionalities are documented and some small example snippets > are added to the documentation. > > > > I hope these changes make sense to you, if the documentation is not > > accurate enough or the naming of cmake properties/variables should be > > changed please let me know > > Would you mind dividing these changes into feature sized patches that I can > review, test and integrate individually? > I hoped I could avoid this :-). Of course I can split it up. Another thing: I just found out that I broke the patch-concept of the WIX generator and that using a patchfile supports adding service installation and handling. So I will remove the unnecessary features I added before submitting the splitted patches. Will take a little time. > Thanks! > Nils Best Regards Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Improved WIX support
Hello there, in short: I fixed some minor issues with WIX toolset support and added the possibility to integrate service installation/uninstallation with generated msi packages. Please review and comment what is missing for integration in upstream. a bit longer: When creating a component-based installer, the root component (or feature, as it is called in WIX context) cannot be named and described. This can now be done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION. The install folder can only be set to a subfolder of ProgramFiles or ProgramFiles64. With the option CPACK_WIX_SKIP_PROGRAM_FOLDER it is now possible to set default installation paths on arbitrary locations such as "C:\myprogram". In order for this to work, the Guids of the WIX-Components must be explicitly set using CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the Guids are auto generated using the value "*". Disabling components by default using the CPACK_COMPONENT__DISABLED is now working. With the install file properties CPACK_WIX_KEYPATH and CPACK_WIX_PROPERTY_ it is now possible to add custom tags (such as service handling) to the installer. If the custom tag depends on several files within the directory, bundling of several files in WIX-Components is needed. This can be done using CPACK_WIX_BUNDLE_COMPONENTS. All new functionalities are documented and some small example snippets are added to the documentation. I hope these changes make sense to you, if the documentation is not accurate enough or the naming of cmake properties/variables should be changed please let me know Best Regards Michael Stürmer 0001-improved-WIX-support.patch Description: 0001-improved-WIX-support.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support ready for review
Uhm, I have to admit that I have not experience in unity development at all so this is not that much of a simple question for me. But my main motivation for native C# support in CMake was to be able to mix native C++, managed C++ and C# binaries within one solution and to build them all together. If this is what you would like to do: yes this works well for me. best regards, Michael > -Original Message- > From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] > On Behalf Of Jean-Michaël Celerier > Sent: Monday, March 21, 2016 9:26 AM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > Simple question : do you think that this would be useable in order to have a > single build pipeline based on CMake for a Unity3D project that also requires > some native C++ libs ? > > Thanks ! > > > On Mon, Mar 21, 2016 at 8:09 AM, Stuermer, Michael SP/HZA-ZSEP > <michael.stuer...@schaeffler.com> wrote: > > Sorry for asking, but do you mean > > > > 1. without support for ninja/nmake/make there is no use having C# > > support in cmake > > > > or > > > > 2. using the current approach this could also work with the other > > generators without too much additional work > > > > ? > > > > I'm just a little confused and try to find out what's on my todo list until > > C# > support may reach a mature level. > > > > best regards, > > Michael > > > >> -Original Message- > >> From: David Cole [mailto:dlrd...@aol.com] > >> Sent: Tuesday, March 08, 2016 12:51 AM > >> To: Brad King > >> Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > >> Subject: Re: [cmake-developers] C# support ready for review > >> > >> Seems to me like C# support should work just fine with other generators: > >> ninja, nmake, and UNIX Makefiles included. Especially with mono on > >> Linux/Mac. > >> > >> > >> David > >> > >> > On Mar 7, 2016, at 2:12 PM, Brad King <brad.k...@kitware.com> wrote: > >> > > >> >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> >> The part that probably needs most additional work is all the C# > >> >> detection and configuration part in the module scripts. > >> > > >> > In your branch Modules/CMakeDetermineCSharpCompiler.cmake > >> currently > >> > has a lot of logic and environment checks for this. It shouldn't > >> > need to be that complicated. Anything requiring deep introspection > >> > of the system (especially the registry) should be something done in > >> > the C++ generator implementation and provided to CMake platform > >> > files as a variable. > >> > > >> > For example, the VS generators always provide msbuild: > >> > > >> > > >> > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > >> AND.ht > >> > ml > >> > > >> > For the path to the compiler tool, take a look at > >> > > >> > Modules/CompilerId/VS-10.vcxproj.in > >> > > >> > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all > >> > runs while detecting the compiler id using a small test project. > >> > It has a custom command that searches the PATH in the IDE project > >> > build environment to print out the path to the compiler. You > >> > should create one like this for CSharp too. > >> > > >> > We'll also need to define behavior when CSharp is enabled by > >> > projects under a non-VS generator. Other generators should reject > >> > any such attempt with an error message. > >> > > >> > Thanks, > >> > -Brad > >> > > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For > >> > more > >> information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source pro
Re: [cmake-developers] C# support ready for review
Sorry for asking, but do you mean 1. without support for ninja/nmake/make there is no use having C# support in cmake or 2. using the current approach this could also work with the other generators without too much additional work ? I'm just a little confused and try to find out what's on my todo list until C# support may reach a mature level. best regards, Michael > -Original Message- > From: David Cole [mailto:dlrd...@aol.com] > Sent: Tuesday, March 08, 2016 12:51 AM > To: Brad King > Cc: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > Seems to me like C# support should work just fine with other generators: > ninja, nmake, and UNIX Makefiles included. Especially with mono on > Linux/Mac. > > > David > > > On Mar 7, 2016, at 2:12 PM, Brad King <brad.k...@kitware.com> wrote: > > > >> On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > >> The part that probably needs most additional work is all the C# > >> detection and configuration part in the module scripts. > > > > In your branch Modules/CMakeDetermineCSharpCompiler.cmake > currently > > has a lot of logic and environment checks for this. It shouldn't need > > to be that complicated. Anything requiring deep introspection of the > > system (especially the registry) should be something done in the C++ > > generator implementation and provided to CMake platform files as a > > variable. > > > > For example, the VS generators always provide msbuild: > > > > > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > AND.ht > > ml > > > > For the path to the compiler tool, take a look at > > > > Modules/CompilerId/VS-10.vcxproj.in > > > > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all > > runs while detecting the compiler id using a small test project. > > It has a custom command that searches the PATH in the IDE project > > build environment to print out the path to the compiler. You should > > create one like this for CSharp too. > > > > We'll also need to define behavior when CSharp is enabled by projects > > under a non-VS generator. Other generators should reject any such > > attempt with an error message. > > > > Thanks, > > -Brad > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support ready for review
Thanks for the hints, I will adapt the C# detection. best regards, Michael > -Original Message- > From: Brad King [mailto:brad.k...@kitware.com] > Sent: Monday, March 07, 2016 8:12 PM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: Gilles Khouzam; CMake Developers > Subject: Re: [cmake-developers] C# support ready for review > > On 02/25/2016 05:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > The part that probably needs most additional work is all the C# > > detection and configuration part in the module scripts. > > In your branch Modules/CMakeDetermineCSharpCompiler.cmake currently > has a lot of logic and environment checks for this. It shouldn't need to be > that complicated. Anything requiring deep introspection of the system > (especially the registry) should be something done in the C++ generator > implementation and provided to CMake platform files as a variable. > > For example, the VS generators always provide msbuild: > > > https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMM > AND.html > > For the path to the compiler tool, take a look at > > Modules/CompilerId/VS-10.vcxproj.in > > and use of it by Modules/CMakeDetermineCompilerId.cmake. That all runs > while detecting the compiler id using a small test project. > It has a custom command that searches the PATH in the IDE project build > environment to print out the path to the compiler. You should create one > like this for CSharp too. > > We'll also need to define behavior when CSharp is enabled by projects under > a non-VS generator. Other generators should reject any such attempt with > an error message. > > Thanks, > -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support ready for review
Ok, this leads me to the question: what is needed/missing for acceptance to 'master'? More Documentation? More Tests? What features have to be provided by the module scripts? Probably some code formatting (I surely missed some indentation stuff and tabs instead of spaces)... I am currently facing the problem that everything works well for me and I don't know what features would be required by others to work with the module. I got two points: - make LangVersion configurable - detect MSBuild from registry Are there additional things missing for general use of the C# support? best regards, Michael > -Original Message- > From: Robert Goulet [mailto:robert.gou...@autodesk.com] > Sent: Monday, February 29, 2016 3:16 PM > To: Stuermer, Michael SP/HZA-ZSEP; Gilles Khouzam; CMake Developers > Subject: RE: C# support ready for review > > As soon as this is merged in 'master' I will give it a try. We are extremely > interested to have C# support in CMake. That is the last piece of our entire > toolchain that is currently not using CMake, so it would be more than > welcome to have the entire system built with CMake. > > Good job! > > -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Stuermer, Michael SP/HZA-ZSEP > Sent: Thursday, February 25, 2016 5:52 AM > To: Gilles Khouzam <gilles.khou...@microsoft.com>; CMake Developers > <cmake-developers@cmake.org> > Subject: Re: [cmake-developers] C# support ready for review > > Hi Gilles, > > good to hear C# support is working not only for me and some people are > actually interested in it :-). > > Thanks for the patch, I already added to my github. All the changes make > perfectly sense for me. > > Let me explain a bit more about things like hardcoding LangVersion in the > module scripts etc. (in short, there is no reason for hardcoding langversion > 3): > > The current C# support was developed by plain trial-and-error. I started out > copying the CXX compiler module scripts, finding out the relevant/necessary > variables, trying to find reasonable values etc. By starting with a copy of > the > CXX scripts I am quite sure there are some leftovers that do not make sense > there. To adapt everything for C# I started by looking at a existing .csproj > file > and changing the target generator until everything went as expected. Initial > values like the flags in CMakeCSharpInformation.cmake where copied as is > from my first simple reference .csproj files. Also the special handling of > .xaml, > .xaml.cs and .Designer.cs files with the tags was just > introduced when I realized I need it somewhere in our new project. > > Putting it all together I just want to say that the current state of > development > leaves room for a lot of improvement and if something seems like it could be > done better, this is most probably the case. I really only pushed it to a > level > where I feel it's working well enough for me and I can focus on my actual job. > > The part that probably needs most additional work is all the C# detection and > configuration part in the module scripts. I got it all up and running so we > can > develop our C/C++/C# cross-platform software here, but it's still some steps > away from a perfectly configurable solution where everyone could be happy. > > best regards, > Michael > > > From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com] > Sent: Thursday, February 25, 2016 8:44 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: RE: C# support ready for review > > Hi Michael, > > Things are looking really good, I've just converted one of my personal > projects to using CMake in very little time. > > I've included a small patch for your CSharp implementation. > > The first change is to add support to specify C# 6.0 in the flag table. > The second removes the exception handling tag and the precompiled header > tags since they don't make sense for C#, as well as adding a space between > the platform comparisons. The space is not necessary for the project, but is > you make any change in the property page inside of VS, a new property > group is created instead of modifying the existing one. While this would not > be a typical CMake scenario, it might be better to stay consistent with how > VS and MSBuild process the file. > > The next thing that I want to start looking at, is to make this work for > Windows Phone and Windows Store apps, so that it can match the support > that we have with C++ in this regards. > > From: Gilles Khouzam > Sent: Wednesday, February 24, 2016 14:47 > To: 'Stuermer, Michael SP/HZA-ZSEP' <michael.stuer...@schaeffler.com>; > CMak
Re: [cmake-developers] C# support ready for review
Hi Gilles, good to hear C# support is working not only for me and some people are actually interested in it :-). Thanks for the patch, I already added to my github. All the changes make perfectly sense for me. Let me explain a bit more about things like hardcoding LangVersion in the module scripts etc. (in short, there is no reason for hardcoding langversion 3): The current C# support was developed by plain trial-and-error. I started out copying the CXX compiler module scripts, finding out the relevant/necessary variables, trying to find reasonable values etc. By starting with a copy of the CXX scripts I am quite sure there are some leftovers that do not make sense there. To adapt everything for C# I started by looking at a existing .csproj file and changing the target generator until everything went as expected. Initial values like the flags in CMakeCSharpInformation.cmake where copied as is from my first simple reference .csproj files. Also the special handling of .xaml, .xaml.cs and .Designer.cs files with the tags was just introduced when I realized I need it somewhere in our new project. Putting it all together I just want to say that the current state of development leaves room for a lot of improvement and if something seems like it could be done better, this is most probably the case. I really only pushed it to a level where I feel it's working well enough for me and I can focus on my actual job. The part that probably needs most additional work is all the C# detection and configuration part in the module scripts. I got it all up and running so we can develop our C/C++/C# cross-platform software here, but it's still some steps away from a perfectly configurable solution where everyone could be happy. best regards, Michael From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com] Sent: Thursday, February 25, 2016 8:44 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Things are looking really good, I've just converted one of my personal projects to using CMake in very little time. I've included a small patch for your CSharp implementation. The first change is to add support to specify C# 6.0 in the flag table. The second removes the exception handling tag and the precompiled header tags since they don't make sense for C#, as well as adding a space between the platform comparisons. The space is not necessary for the project, but is you make any change in the property page inside of VS, a new property group is created instead of modifying the existing one. While this would not be a typical CMake scenario, it might be better to stay consistent with how VS and MSBuild process the file. The next thing that I want to start looking at, is to make this work for Windows Phone and Windows Store apps, so that it can match the support that we have with C++ in this regards. From: Gilles Khouzam Sent: Wednesday, February 24, 2016 14:47 To: 'Stuermer, Michael SP/HZA-ZSEP' <michael.stuer...@schaeffler.com>; CMake Developers <cmake-developers@cmake.org> Subject: RE: C# support ready for review Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuer...@schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam <gilles.khou...@microsoft.com>; CMake Developers <cmake-developers@cmake.org> Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review H
[cmake-developers] C# support ready for review (update)
Hello all, here is an update of the C# support patch. I fixed the errors & discrepancies reported by Gilles. Hope it looks better now. My development branch can be found here: https://github.com/micst/CMake/tree/csharp It is in the same state as the patch, but includes a few changes which I need for local building and usage. best regards, Michael From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 3:03 PM To: CMake Developers Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael 0001-prepared-CSharp-support.patch Description: 0001-prepared-CSharp-support.patch 0002-implemented-CSharp-support.patch Description: 0002-implemented-CSharp-support.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support ready for review
Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers <cmake-developers@cmake.org<mailto:cmake-developers@cmake.org>> Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] C# support ready for review
Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: - VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) - VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) - VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael 0001-prepared-C-support.patch Description: 0001-prepared-C-support.patch 0002-implemented-C-support.patch Description: 0002-implemented-C-support.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Code style auto-formatting
> -Original Message- > From: Kislinskiy, Stefan [mailto:s.kislins...@dkfz-heidelberg.de] > Sent: Tuesday, November 17, 2015 10:11 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: AW: [cmake-developers] Code style auto-formatting > > Do you know ClangFormat[1]? Pretty popular choice these days. You just put > a format description file into your repository (which can be based on popular > styles + your exceptions to keep the file rather small). It can be integrated > into many editors including the Visual Studio IDE. Sounds promising. For CMake a configuration file would be needed which changes the existing code as less as possible. If something like that exists and it is easy to handle I believe some developers might use it. Still someone would have to do the work of setting up/configuring everything :-) . > You probably want to add a > hook to your git repository to automatically format your code when > committing. See the link for details. Ok, this is only my opinion, but changing the actual changeset automatically within a commit hook is one oft he worst things you can do with hook scripting. Style checking or refusal of badly styled code is ok. > > Best regards, > Stefan > > [1] http://clang.llvm.org/docs/ClangFormat.html > > > Von: cmake-developers [cmake-developers-boun...@cmake.org] im > Auftrag von Stuermer, Michael SP/HZA-ZSEP > [michael.stuer...@schaeffler.com] > Gesendet: Dienstag, 17. November 2015 09:14 > An: CMake Developers > Betreff: Re: [cmake-developers] Code style auto-formatting > > I asked something similar half a year ago: > > https://cmake.org/pipermail/cmake-developers/2015-June/025498.html > > In short, there is no fully automated style checking. If someone would come > up with a tool & configuration I would love to use this. So far I tested > astyle > and the C++ edition of ReSharper (unfortunately quite expensive). > > The more complicated thing would be, that you have to run the formatter > over all existing code and thus you would introduce a huge amount of > meaningless changes. I believe (and partially understand) many developers > here on the list wouldn't really like large cosmetic changes like this. > > best regards, > Michael > > > -Original Message- > > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > > On Behalf Of Robert Dailey > > Sent: Tuesday, November 17, 2015 3:01 AM > > To: CMake Developers > > Subject: [cmake-developers] Code style auto-formatting > > > > IMHO, the code style in the CMake code base is incredibly > > inconsistent, but even the consistent style that is there is a giant pain to > follow by hand. > > > > I'm constantly fighting my tooling's auto formatting. I prefer to keep > > my code additions similar to surrounding code. Do you use some tool > > such as clang- format to auto format code? This will make it easier to > > make my style more consistent after my work is completed. > > > > Thanks in advance. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For > > more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake-developers > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community
Re: [cmake-developers] PATCH: fix sphinx-documentation theme
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Monday, November 16, 2015 4:57 PM > To: cmake-developers@cmake.org > Subject: Re: [cmake-developers] PATCH: fix sphinx-documentation theme > > On 11/16/2015 10:45 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Sphinx does not seem to provide any "default" theme anymore, it's > > called "classic" now. > > Thanks. This was previously discussed here: > > https://cmake.org/pipermail/cmake/2015-July/061096.html > > Upstream Sphinx has decided to drop the warning: > > https://github.com/sphinx- > doc/sphinx/commit/034c4e942451fad40350ae3bb3beda6c63a49064 > > > It might even be better to make the html_theme value a cmake variable > > in the build process. > > Perhaps, but that will require more extensive changes to configure all the > different places in the source that refer to the theme. > If the `static/cmake.css` file needs to be configured then we might also have > to configure/copy everything else in the entire `static` directory since IIRC > sphinx only has one value for that and not a search path. > > For now it is simplest to ignore the warning from Sphinx or upgrade to a > version of Sphinx that drops the warning. > The warning itself is not the problem, sphinx (at least my current version) simply does not have any "default" theme so the design is completely broken in html view. If newer sphinx versions introduce a fallback to "classic" theme if "default" is configure, it's ok. > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] PATCH: fix sphinx-documentation theme
Sphinx does not seem to provide any "default" theme anymore, it's called "classic" now. I'm not sure if this breaks documentation generation at Kitware, but the documentation on cmake.org is generated using sphinx 1.4a0+ and I'm using 1.3.1 here. It might even be better to make the html_theme value a cmake variable in the build process. Viele Grüße Michael Stürmer SZ. Prozessdatenverarbeitung SP/HZA-ZSEP Tel. +499132 82-86350 Mobil.: +49(171)6860010 [cid:image001.png@01D04C4A.A332A300] 0001-changed-sphinx-theme-to-classic.patch Description: 0001-changed-sphinx-theme-to-classic.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support status?
Hi, there is an initial implementation on my github: https://github.com/micst/CMake Check out the "csharp" branch. It merges well with the current master of CMake (last test yesterday, but not yet pushed to github). I would love to see this in upstream some day, but currently quite a bunch of work is missing until it can get accepted: - the module scripts for finding and configuring the compiler should be improved, I just hacked them so that my build here works - documentation does not really exist. I added a few target- and file-properties that need explanation as well as some automated bundling of .resx|.settings|.Designer.cs|.xaml files with corresponding .cs sources. - tests ... well they are missing as well :( At the moment only visual studio generator and only version 2013 is accepted/implemented. It should not be a big task to enhance it to support 2015 as well. It would be great to have at least nmake, but I have absolutely no time right now to continue my work on C# support for CMake. I have a test-project for testing the C# support on github https://github.com/micst/CMakeCSharpTest but I'm not sure if it still works as didn't run it for quite some time. Please let me know if you like to contribute in any way to this. Best Regards Michael Stürmer SP/HZA-ZSEP Postcode HZA 13-4-06 SZ.Prozessdatenverarbeitung Schaeffler Technologies AG & Co. KG Industriestraße 1-3 91074 Herzogenaurach (Germany) Tel. +49 91 32 / 82 - 86350 · Fax +49 91 32 / 82 - 45 86350 Mobil.: +49 171 6860010 mailto:michael.stuer...@schaeffler.com<mailto:stefan.soutsc...@schaeffler.com> · http://www.ina.de<http://www.ina.de/> Registered Seat: Herzogenaurach Commercial Register: AG Fürth HRA 9349 General Partner: INA Beteiligungsgesellschaft mit beschränkter Haftung Registered Seat: Herzogenaurach (Germany) Commercial Register: AG Fürth HRB 2379 Managing Directors: Klaus Rosenfeld (CEO), Prof. Dr. Peter Gutzmer, Norbert Indlekofer, Oliver Jung, Kurt Mirlach, Prof. Dr. Peter Pleus, Robert Schullan This e-mail message is intended only for the use of the named recipient-(s) and contains information which may be confidential or privileged. If you are not the intended recipient, be aware that any distribution, or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender and delete the material from the computer. From: Robert Goulet [mailto:robert.gou...@autodesk.com] Sent: Monday, November 02, 2015 10:25 PM To: Stuermer, Michael SP/HZA-ZSEP; cmake-developers@cmake.org; Gilles Khouzam Subject: C# support status? Hi, I saw a C# support thread some time ago, and I was wondering what is the status of this so far. Is there an initial implementation merged in any branch? Here at the office we are using CMake to generate projects for our game engine (all platforms), however the editor itself has some C# code, and preferably we would want to generate the .csproj files with CMake as well. We are also available to test this implementation once it is merged in any CMake branch. We have the ability to test it with VS2015 if that matters. Thanks! -Robert Goulet -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support?
Hi all, some minor updates to the patches. There where 2-3 bugs somewhere... https://github.com/micst/CMake/tree/csharp is up to date. best regards, Michael -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Thursday, July 02, 2015 3:54 PM To: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? Hi all, I got the first sort of working version running. Would be great if some people could have a look at it if it's going into a good direction. Some explanations: Patch 0001: - adds the necessary Module/* files for enabling C# as a language - CAUTION: only Visual Studio 2013 generators are supported at the moment - there is a verbose message which is shown when C# is used to guide people where to go for improvement Patch 0002: - some minor changes to mostly visual studio related classes to enable .csproj support o .csproj GUID is added o a method to check if the target is C# is added Patch 0003: - the actual implementation of the .csproj generation - all generation takes place inside VisualStudio10TargetGenerator class There is an example project in the appendix of this mail which you can use to see how .csproj can be generated now. And yes, there are still quite some things missing: - Tests () - NMake support (even though that should not bee too hard) o better handling of the flagtable that I added (not sure if I understood correctly how the concept is supposed to be used) - documentation () Most questions on how to use the C# language and mixing with C++ targets should be answered by looking at the example project. Some VS_* target properties already existed which I reused. I added two Property-Groups: - VS_DOTNET_REFERENCE_NAMEproperties for references with a Hint tag, though they also can be added to the normal VS_DOTNET_REFERENCES. This is a target-property - CSharpPROJ_name the tag name will be added to the Compile tag of the specified Source files. This is a source property. - CSharpPROJ_SubTypethe currently only used case of above property group. It's needed to tell visual studio what kind of file is added. You can safely omit this, but visual studio will not be able to run the designer in the correct mode without it. Project references are added by simply using target_link_libraries(). All other references must use done in one of the above described ways. It would be great if some people could try if the example project works for them. If you have improvements don't hesitate to submit any patch to my current fork on github (branch csharp): https://github.com/micst/CMake.git The example project can be found there as well: https://github.com/micst/CMakeCSharpTest.git best regards, Michael -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Tuesday, June 30, 2015 3:49 PM To: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: it would be great if some people could step forward once everything is running from my side to help get makefile and linux support (and test other Visual Studio versions). Once you have it working in VS 2013 the other VS = 2010 versions should be easy. I'm not sure about other generators yet. If you have good coverage in the test suite updates then that will make the task of adding support to other generators easier. For now you can have CMakeDetermineCSharpCompiler do a message(FATAL_ERROR) when CMAKE_GENERATOR is set to a value that is not supported. That can be lifted when the other generators implement the language. About enable_language(): have the appropriate cmake-scripts in Module directory [snip] Almost everything relevant goes in the target generator class VisualStudio10TargetGenerator. Great! Once done, do you want patchfiles here on the list or a pull request from my fork on github? Please send patch files here as requested in CONTRIBUTING.rst. Please re-organize commits into a logical series of updates rather than the original unorganized development history. Thanks! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http
Re: [cmake-developers] C# support?
Hi and thanks for all your answers, Let me give you some information how things are implemented so far and where my constraints in implementing C# support are: At the moment I have only Visual Studio 2013 available, which makes it hard for me to test any other generators. NMake is not a priority for me, but the concept of the Visual Studio generators in CMake is so nice implemented, that it should not be much of a problem to get this running. I will have a look on this once Visual Studio generators are working. I will be able to test some linux/mono functionality in VirtualBox, but I will most probably not have much time. We are working on Windows based software here and I will not be allowed to spent a vast amount of time working on non-project related topics. In short: it would be great if some people could step forward once everything is running from my side to help get makefile and linux support (and test other Visual Studio versions). About enable_language(): Working. From my knowledge it's mainly about have the appropriate cmake-scripts in Module directory. That's done, my test project builds well with it. Ok, the CMakeTest... script simply sets WORKS to true ... that could be improved ... About .csproj files: It's almost done, the files are generated already and working well. There still needs to be some cleaning and generalization to use parameters instead of hard coded information. About intrusiveness: Almost everything relevant goes in the target generator class VisualStudio10TargetGenerator. The necessary .cmake files for the language are added and some minor changes to other generator sources are needed (for setting target type GUID in .sln etc.). All changes so far are made to be as minimal as possible to the original cmake sources and I believe it blends in quite well. Credit goes to the guys who implemented the VisualStudio generator concept with the flagmaps. You need some time to understand it, but once you've got it it's really great. About C#/.NET: I'm new to .NET and C# as well, but it seems not to provide too many surprises. Nevertheless some challenges remain to come up with a good solution for C# integration. It's mainly about reference handling. I have a working example at the moment, but it could be improved further. About the language: Would it be ok to name the language in CMake CS instead of CSharp? I did everything as CS so far... About contributing: Once done, do you want patchfiles here on the list or a pull request from my fork on github? --- If someone is interested in the development so far, you can check out my CMake fork here (have a look at the csharp branch): https://github.com/micst/CMake.git The test project with mixed C++/C# targets, cross-referencing from C++ -- managed C++ -- C# can be found here: https://github.com/micst/CMakeCSharpTest.git best regards, Michael -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of David Cole via cmake-developers Sent: Monday, June 29, 2015 7:31 PM To: Brad King Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? The C# compiler, csc.exe, takes all its arguments at once in one call to build a library or executable. Listing all the sources, and its references (other libraries it depends on) all at once. You can do it as command line arguments, or as contents of a response file, or a combination or arguments plus response file. Conceptually, it's just like Java. They do have separate project files for it with VS, though. The generators will need code to generate *.csproj files, rather than custom commands in a vcxproj file, to make it seem like it's really well-integrated with VS. Not sure if *.csproj files have evolved much over the last few releases of VS -- I'd expect the major challenge with this to be making sure CMake generates proper *.csproj files for however many versions of VS it would take to make it acceptable. D On Mon, Jun 29, 2015 at 1:05 PM, Brad King brad.k...@kitware.com wrote: On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote: Does it have a realistic chance to be accepted for upstream Yes, so long as it comes with proper tests and is not too intrusive on the overall design/implementation of CMake. In order to enable use of C# sources we should get enable_language(CSharp) to work. This is likely straightforward with the VS generators. One question is how things should be done for the Makefile and Ninja generators. For these we need to construct command line invocations of the compiler. I'm not very familiar with C#. Does it need separate compilation with dependencies or should one simply invoke the compiler with the entire list of sources in a response file or something? Thanks, -Brad -- Powered by www.kitware.com Please keep
Re: [cmake-developers] C# support?
Sounds reasonable, my choice was motivated by the file extension of the C# source files (.cs) and that it is shorter. But as Fortran seems to use the longer “Fortran” description it might be a good idea to switch to “CSharp” as well … Michael From: Petr Kmoch [mailto:petr.km...@gmail.com] Sent: Tuesday, June 30, 2015 10:18 AM To: Stuermer, Michael SP/HZA-ZSEP Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP michael.stuer...@schaeffler.commailto:michael.stuer...@schaeffler.com wrote: [...] About the language: Would it be ok to name the language in CMake CS instead of CSharp? I did everything as CS so far... If I may provide an outsider's comment on this point, I would suggest against this. For me, CS does not intuitively associate with C# - I wouldn't know it means C# unless I read it somewhere stated explicitly. C, CXX, Fortran are all obvious to me, CS is not. Then again, I have never used C#, so it might just be general unfamiliarity on my part, in which case feel free to ignore this post. Petr -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] C# support?
Hi and sorry for cross-posting this on both lists, I checked the mailing list history about the C#/.NET support topic and realized that the interest in C# support seems to have declined a bit. I am right now in the need of good C# support and adding external project files is not that much of an option to me. So I started hacking away everything that is needed for .csproj generation and support of mixed managed/unmanaged targets. Not yet done, but there is a light at the end of the tunnel. Now the question: is there any real interest at all in this feature? Does it have a realistic chance to be accepted for upstream or will I have to maintain my own fork of CMake? best regards, Michael Stürmer -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] astyle cofiguration for CMake coding?
Does anyone have a configuration for astyle which indents my code according to the CMake coding rules? Would make my life much easier right now. Directions where I can find a complete set of rules how the code should be formatted would also suffice. best regards Michael Stürmer -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] astyle cofiguration for CMake coding?
Thanks, I think this should be enough for me to configure the visual studio plugin accordingly. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Monday, June 22, 2015 3:43 PM To: Stuermer, Michael SP/HZA-ZSEP; cmake-developers@cmake.org Subject: Re: [cmake-developers] astyle cofiguration for CMake coding? On 06/22/2015 03:36 AM, Stuermer, Michael SP/HZA-ZSEP wrote: Directions where I can find a complete set of rules how the code should be formatted would also suffice. We don't have it formally documented anywhere. Basics: * 79 columns or less (only one that is enforced with a test) * indent with 2 spaces, no tabs * opening '{' gets its own line and aligns with inner code * CamelCase names for class members * this-Member for references to class members Generally just try to match style of surrounding code. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] fixed msvc 64 bit build
-Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Monday, June 15, 2015 4:11 PM To: Stuermer, Michael SP/HZA-ZSEP Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [PATCH] fixed msvc 64 bit build On 06/15/2015 07:58 AM, Stuermer, Michael SP/HZA-ZSEP wrote: This is just a one-char-bugfix, WIN32 instead of _WIN32 macro was used. Thanks. There are several instances of this in Source/*. I've fixed the one you pointed out and more: Fix preprocessor checks WIN32 = _WIN32 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83af11d4 There is one other in Source/kwsys that I've fixed in upstream KWSys: http://review.source.kitware.com/19926 and will integrate back to CMake after testing there. Are there any regular Win64 builds done actually? Yes. We have nightly testing for it which has been clean. It is also my main Windows development architecture. The WIN32 symbol is normally defined by CMAKE_CXX_FLAGS if the default flags are used for MSVC. How did you configure the build? -Brad My setup was roughly: - Visual Studio 2013 - CMake 3.0.2 - Qt4.8.6 - Qt dialog enabled - Documentation enabled - cpack with NSIS WIX enabled - no special compiler configuration or so ... I can not really reproduce if there was something broken in my CMake installation as I replaced it after successful build, but I didn't change any flags deliberately. It doesn't really matter, but isn't the WIN32 symbol defined in a common place for both 32 and 64 bit configurations? This makes it a bit interesting, as the 32 bit build worked flawlessly. Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] if absolute path of a used tool (*_PROG) contains white spaces, generation of documentation may fail
I have doxygen, gnuplot, html help and the UnxUtils in C:\Program Files (x86)\ This leads to errors when using one of these tools. I hope putting some around tool-names does not break anything on linux. Best Regards Michael Stürmer 0001-if-absolute-path-of-a-used-tool-_PROG-contains-white.patch Description: 0001-if-absolute-path-of-a-used-tool-_PROG-contains-white.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] fixed msvc 64 bit build
This is just a one-char-bugfix, WIN32 instead of _WIN32 macro was used. Sorry if I should have opened up a ticket in mantis before posting here. Just didn't know what would be correct order. Are there any regular Win64 builds done actually? I'm just curious if there is anyone else using 64bit versions of CMake on Windows ... Best regards Michael Stürmer 0001-fixed-msvc-64-bit-build.patch Description: 0001-fixed-msvc-64-bit-build.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers