Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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)

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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: 

Re: [CMake] IMPORTED DLL-only Target on MSVC

[Stuermer, Michael SP/HZA-ZSEP]

> -Ursprüngliche Nachricht-
> Von: CMake [mailto:cmake-boun...@cmake.org] Im Auftrag von Marek
> Vojtko (Firaxis)
> Gesendet: Dienstag, 3. April 2018 23:24
> An: cmake@cmake.org
> Betreff: Re: [CMake] IMPORTED DLL-only Target on MSVC
> 
> > > Is it not possible to wrap an external DLL-only library in an IMPORTED
> target?
> > >
> >
> > Yes it is.
> >
> > > I have an external dependency that is a single DLL (shared library)
> > > and a header file, but no LIB (static library) file.
> >
> > How does this work in Visual Studio C++? If I am not completely
> > mistaken you ALWAYS need a .lib file along with your .dll to link to
> > the shared library. And you Need a header with the API as well of course.
> >
> > The only case I know with .dll and without .lib file is when you have
> > managed
> > C++ or C# targets.
> >
> 
> The DLL gets loaded using LoadLibrary("MyDependency.dll") at runtime and
> its functions are accessed through GetProcAddress():

Ok, I missed this case :-). But in my opinion MyDependency.dll is not a TARGET 
in
the sense of CMake targets. It's just a variable/filename which is used in the 
project
somewhere. This is actually also how Visual Studio treats the .dll: you only 
pass
the filename somewhere, not mentioning "link to this" or something else.

If you want to deploy/copy the .dll to your binary directory I'd simply add a
POST_BUILD custom command which copies the file over so you don't have to
do it manually.

> 
> HINSTANCE hLib = LoadLibrary(DLL_NAME);
> If(hLib)
> {
> typedef int (*DLL_FUNC)();
> myFunc = (DLL_FUNC)GetProcAddress(hLib, "DLLFunction"); }
> 
> Like I said, it's an external dependency and I don't have any control over it.
> The dependency's include directories have to be added to my executable's
> include directories and I need to copy the DLL next to the executable. I
> thought I'd solve (at least the include directories) by creating an IMPORTED
> target, but no matter what I try, the DLL ends up in the linker command line,
> wreaking havoc.

Adding include directories/files only via target could be done by putting the
Include files in a INTERFACE library. Not sure if this is an elegant solution 
for
your case but I'd probably start like this.

> 
> Of course I can work around this issue by not creating an IMPORTED target
> and just relying on two variables (MyDependency_INCLUDE_DIR and
> MyDependency_SHARED_LIB). Before I do, however, I wanted to make sure
> that CMake does not in fact support a DLL-and-header-only library set up.
> 
> Thanks,
> Marek
> 
> --
> 
> 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
-- 

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

Re: [CMake] IMPORTED DLL-only Target on MSVC

[Stuermer, Michael SP/HZA-ZSEP]

> -Ursprüngliche Nachricht-
> Von: CMake [mailto:cmake-boun...@cmake.org] Im Auftrag von Marek
> Vojtko (Firaxis)
> Gesendet: Dienstag, 3. April 2018 00:49
> An: cmake@cmake.org
> Betreff: [CMake] IMPORTED DLL-only Target on MSVC
> 
> Hi,
> 
> Is it not possible to wrap an external DLL-only library in an IMPORTED target?
> 

Yes it is.

> I have an external dependency that is a single DLL (shared library) and a
> header file, but no LIB (static library) file. When I create an IMPORTED 
> target

How does this work in Visual Studio C++? If I am not completely mistaken you
ALWAYS need a .lib file along with your .dll to link to the shared library. And 
you
Need a header with the API as well of course.

The only case I know with .dll and without .lib file is when you have managed
C++ or C# targets.

> and depend on it via target_link_libraries() I run into linkage issues, 
> because
> on MSVC CMake puts the DLL into the linker command (the "Input" text field
> in the "Linker" settings of the Project Properties).
> 
> add_library( MyDependency::MyDependency MODULE IMPORTED )
> set_target_properties( MyDependency::MyDependency
> PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}"
> IMPORTED_LOCATION "${MyDependency_SHARED_LIB}"
> )
> [..]
> add_executable( MyExecutable ... )
> target_link_libraries( MyExecutable PRIVATE
> MyDependency::MyDependency )
> 
> I tried changing the library type in my add_library() call:
> - STATIC obviously didn't work, because I don't have a .lib file and the .dll 
> file
> in IMPORTED_LOCATION was added to MyExecutable's linker line.
> - SHARED did not work because CMake expects a .dll in
> IMPORTED_LOCATION and a .lib in IMPORTED_IMP_LOCATION, so
> MyExecutable's linker line had a MyDependency::MyDependency-
> NOTFOUND entry in it.
> - MODULE seemed like the right choice when reading the documentation,
> but MyExecutable's linker line still contains the .dll file specified in
> IMPORTED_LOCATION.
> 
> What am I doing wrong?
> 
> Thanks,
> Marek
> 
> --
> 
> 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
-- 

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

[cmake-developers] [SOLVED] CMake build with static crt and static QtDialog not linking

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

> 
> 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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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] CMake 3.8 release date

[Stuermer, Michael SP/HZA-ZSEP]

Hello Nikita,

Brad mentioned a feature freeze for version 3.8 at the end of january. Looking 
at the source history for version 3.7, it can take some time until the final 
release is done:

3.10.2016: (candidate 1)
19.10.2016: (candidate 2)
4.11.2016: (candidate 3)
11.11.2016: (final release)

You can see it can take more than a month until a final release is ready. I 
don’t believe there is a certain fixed date when this is due.

best regards,
Michael

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nikita
Sent: Monday, January 23, 2017 11:35 AM
To: CMake ML
Subject: [CMake] CMake 3.8 release date

Hi,

I couldn't find any release schedule for the project, so I've decided to ask 
about it here. What is the expected release date of CMake 3.8?

I'm interested in it because I'm waiting for this fix: 
https://gitlab.kitware.com/cmake/cmake/issues/16435

Regards,
Nikita


-- 

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

Re: [CMake] Tracing ctest crash on windows

[Stuermer, Michael SP/HZA-ZSEP]

Hallo Aaron,

if you’d like to have the full luxury of visual studio with test explorer and 
running/debugging tests directly as you can do it with other .NET based tests 
etc. you can try these extensions:


-  child process debugging power tools 
(https://marketplace.visualstudio.com/items?itemName=GreggMiskelly.MicrosoftChildProcessDebuggingPowerTool)

-  ctesttestadapter 
(https://github.com/micst/CTestTestAdapter/tree/master/dist)

For debugging tests you need both extensions: the first for hooking on the 
process that is launched by ctest.exe, the second for actual ctest integration 
in visual studio.

Compared to running your binary test-targets directly you will gain the 
advantage that you do not have to modify and debugging command line, you have 
all tests listed in a explorer windows with easy access and you get all verbose 
messages from ctest in the test explorer as well.

The VSIX extension is a fork from https://github.com/toeb/CTestTestAdapter with 
some changes and bugfixes. It's not tested very well but I use it every day and 
it works for me. Do not use the "ctesttestadapter" you can find directly in 
visual studio, it does not work with latest cmake.

CAUTION: If you use the cmaketools extension (http://cmaketools.codeplex.com) 
in Visual Studio, the link to the test location in the test explorer does not 
work (double clicking on a test will show some "could open file location" 
error). This does not break the test adapter, opening the CTestTestfile.cmake 
is just not possible from within Visual Studio.

Michael

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Aaron Boxer
Sent: Thursday, January 05, 2017 9:17 PM
To: Bill Hoffman
Cc: cmake
Subject: Re: [CMake] Tracing ctest crash on windows

Thanks, Bill and Jakob.  I did what you suggested and found the problem
Aaron

On Thu, Jan 5, 2017 at 11:51 AM, Bill Hoffman 
> wrote:
On 1/5/2017 9:32 AM, Jakob van Bethlehem wrote:

CTest is not some magical tool that internally runs your test or
something like that - instead CTest just fires up your test executable
and does clever things with the output. In the same way you can just set
your test project as startup-project, and debug it like any other
executable.

Sincerely,
Jakob

On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer 

>> wrote:

Hello,
I am on windows, with visual studio 2015.
Some of my ctest tests are crashing with exception.
Is there a way of debugging these tests ?

When I run in debug mode, I get an exception dialog,
but can't drop into debugging environment.
If you run ctest -VV it will show the full command line.  Best way is to just 
run the same command in the debugger.

-Bill


--

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

-- 

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

Re: [CMake] Cmake

[Stuermer, Michael SP/HZA-ZSEP]

Hello,

To add your mentioned libraries to the executable you have to link against 
them. For this the cmake command

target_link_libraries() is used: 
https://cmake.org/cmake/help/v3.7/command/target_link_libraries.html

In your case the cmake code should look similar to this:

target_link_libraries(tsm armadillo lidsndfile)

best regards,
Michael

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of aishwarya selvaraj
Sent: Wednesday, December 21, 2016 12:52 PM
To: cmake@cmake.org
Subject: [CMake] Cmake

Hi Everyone,
Myself Aishwarya .I wanted to make use of Cmake , but I'm really new to this 
and doesn't have a clear idea about it.
1) My Goal :
I'm using Praat a speech Processing Software to create plug - in for my 
Algorithm on Pitch and Time scaling .(I have the .cpp file)
In order to do that I need to use the binary file obtained by compiling .cpp 
file
​in my Praat Script .
I intent to share this plug - in with others ,Hence I want it to be machine 
independent .The binary file I obtained is using gcc in Linux (16.0.2), which 
clearly wont work in Mac or Windows or even in lower Linux Version.
To solve this Problem I understand that I need to make use of Cmake files .
2) My .cpp file called TSM_CODE_V3.cpp is compiled as
g++ TSM_CODE_V3.cpp -larmadillo -lsndfile -o TSM
where armadillo and sndfile are two depended libraries.

3) What I have done :
​I have gone through a loot of tutorials for cmake .I have wage idea , but I'm 
not able to solve my problem mentioned above .
​My folder TSM consists of
build - the folder which consists the final executable binary file and the 
related cmake files required to create binary file
src - consists of my TSM_CODE_V3.cpp code
CMakeLists.txt - The top level Cmake file :

 cmake_minimum_required(VERSION 2.8.9)
 project(directory_TSM)
 include_directories(include)
 file(GLOB SOURCES "src/*.cpp")
 add_executable(tsm ${SOURCES})

I need to include the library armadillo and lidsndfile .
I dont know how to include it into my cmakefile .
I have come across find_package ,find_library  but I am sure about it .
 To create my Praat Plug - in I need to compile the source code no matter in 
which system it is ,which may or may not have these two libraries already 
installed.
So how how do I add libraries using cmake ?
I hope you got my point .
Could help me ?

Hoping for your reply .

--
Regards,
Aishwarya Selvaraj
-- 

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

Re: [cmake-developers] GitLab speed

[Stuermer, Michael SP/HZA-ZSEP]

>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 King  wrote:
> >
> > 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?

[Stuermer, Michael SP/HZA-ZSEP]

> -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?

[Stuermer, Michael SP/HZA-ZSEP]

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

Re: [CMake] [cmake-developers] CPack [WiX] Customizations of individual features/components

[Stuermer, Michael SP/HZA-ZSEP]

Hello Roman,

directories are added automatically to the directories.wxs file if you use the 
install() command in cmake and set the DESTINATION to some subfolder:

install(FILES 
DESTINATION "my/sufolder/path")

To add completely new directories I'd suggest to use CPACK_WIX_EXTRA_SOURCES 
and use a  element where you can place your new directories in. 
Untested example how to add a directory (not sure if it works exactly like 
this):


http://schemas.microsoft.com/wix/2006/wi;>
  
   
  
  
  


I'm not sure if patching of  elements is possible/implemented in 
cpack and I believe using the extra sources mechanism is more convenient.

PS: if you want to use the CPACK_WIX_PATCH_FILE nevertheless and you have many 
framents to patch, CPACK_WIX_PATCH_FILE also accepts a list of filenames so you 
can split up your patches in an arbitrary number of files.

best regards,
Michael

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Roman Wüger
> Sent: Friday, September 30, 2016 8:44 AM
> To: CMake Developer MailingList; CMake MailingList
> Subject: [cmake-developers] CPack [WiX] Customizations of individual
> features/components
> 
> Hello,
> 
> I want to customize some with CPack  generated *.wxs files.
> 
> For example: directories.wxs is generated with only the TARGET_DIR.
> 
> How can I add an additional directory in this file and use the newly added
> directory in the components (features.wxs)?
> 
> I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it,
> but if so how?
> 
> Thanks in advance
> 
> Regards
> Roman
> --
> 
> 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

[cmake-developers] [PATCH] preparations for native C# support

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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] Use GLOB to generate filelist for install package

[Stuermer, Michael SP/HZA-ZSEP]

> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Patrik
> Lehmann
> Sent: Thursday, August 11, 2016 11:04 AM
> To: cmake@cmake.org
> Subject: [CMake] Use GLOB to generate filelist for install package
> 
> Hello,
> 
> I try to use GLOB to collect the files for my install package, but 
> unfortunately I
> got the message
> 
> 'file INSTALL cannot find
> "C:/Project/include/test1.h;C:/Project/include/test2.h;...'
> 
> My code:
> 
> FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h")
> 
> INSTALL(FILES "${MY_INCLUDES_H}"
>   DESTINATION "include"
>   COMPONENT CPP_INCLUDES)
> 

Remove the '"' around the list of headers in your install command:

INSTALL(FILES ${MY_INCLUDES_H} ...

instead of 

INSTALL(FILES "${MY_INCLUDES_H}" ...

The quotes result in the list to be expanded in only one long string instead of 
a list of strings. CMake thinks you are only installing one file with a vry 
long name.
 

> 
> Is there a way to collect the files this way or is it needed to add every file
> manually?
> 
> Kind Regards,
> Patrik Lehmann
> --
> 
> 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
-- 

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

Re: [cmake-developers] [Patch 3/5] Improved WIX support

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

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] Custom languages supported by all generators?

[Stuermer, Michael SP/HZA-ZSEP]

Hi Niklas,

native support for C# is not available in CMake. There is some work in 
progress, but it's not yet integrated:

https://github.com/micst/CMake

Unfortunately I haven't had the time yet to adapt the topic to the new 
formatting style, so it doesn't merge well with the current Kitware master 
:-(...

best regards,
Michael

> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Niklas
> Therning
> Sent: Thursday, May 19, 2016 9:27 AM
> To: cmake@cmake.org
> Subject: [CMake] Custom languages supported by all generators?
> 
> Hi,
> 
> I'd like to add support for compiling C# using enable_language(CSharp) to my
> project. Similar to cmake-haskell [1]. Before I attempt this I would like to
> know whether this is something all generators support? I searched through
> the cmake sources and it looked to me like only the Unix Makefiles and Ninja
> generators actually support this? I'm particularly interested in the Xcode and
> Visual Studio generators.
> 
> I'm using cmake 3.5.2 via Homebrew on OS X and cmake 3.5.2 from
> cmake.org on Windows 10.
> 
> [1] https://github.com/kvanberendonck/cmake-haskell
> 
> Thanks!
> /Niklas
> --
> 
> 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
-- 

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

Re: [cmake-developers] C# support ready for review

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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] empty list evaluates to false?

[Stuermer, Michael SP/HZA-ZSEP]

You can check for existence of a variable and you can invert the result of the 
evaluation:

if(DEFINED )
# called if variable exists, never mind if it's empty or not
endif()

if(NOT DEFINED )
# called if variable is not defined
endif()

if(NOT )
# called if variable is empty/false/off
endif()

I think it should be possible to get the expected behavior this way...

best regards,
Michael

> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of ?? Jan
> Hegewald
> Sent: Monday, February 29, 2016 3:12 PM
> To: cmake@cmake.org
> Subject: [CMake] empty list evaluates to false?
> 
> Hi cmakers,
> can I create an empty list which evaluates to true? The way I tried they
> evaluate to false:
> 
> set(BLAS_LIBRARIES "") # trying to create an empty list
> if(BLAS_LIBRARIES)
>   # not called
> endif()
> 
> Cheers,
> Jan
> --
> 
> 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
-- 

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

Re: [cmake-developers] C# support ready for review

[Stuermer, Michael SP/HZA-ZSEP]

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)

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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] CTest integration in Visual Studio TestExplorer

[Stuermer, Michael SP/HZA-ZSEP]

If you have a (example) CMake project which shows your error just let me know. 
I can have a quick look at it.

If you rebuild the ctest adapter with logging enabled, you should not have to 
recompile everything. Uninstalling the current and installing the recompiled vs 
extension should be enough. Once reloading your solution you should see some 
logging messages in the “Test” and in the “CTestAdapter” output window.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Máté Ferenc Nagy-Egri 
via CMake
Sent: Thursday, February 04, 2016 5:51 PM
To: cmake@cmake.org
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer

Indeed, both RUN_TESTS and the CTest files exist, I have even found a file 
created by the add-in which seems to hold correct target names.

Recompiling will take some time, but will try to help with it.

Feladó: Stuermer, Michael  SP/HZA-ZSEP<mailto:michael.stuer...@schaeffler.com>
Feladva: ‎2016.‎02.‎04. 16:27
Címzett: Nagy-Egri Máté Ferenc<mailto:csiga.b...@aol.com>; 
cmake@cmake.org<mailto:cmake@cmake.org>
Tárgy: RE: CTest integration in Visual Studio TestExplorer
Hi Máté,

thanks for trying the extension!

Some questions before going more into details:

-  do you have a CTestTestfile.cmake in your build root i.e. where 
the.sln file is you have opened with Visual Studio?

-  do you have a RUN_TESTS target/project in your visual studio 
solution? It could be in the “CMakePredefinedTargets” folder…

The basic concept of test discovery for the plugin is, to look for a 
CTestTestfile.cmake file in the same folder where the .sln file is. From there 
all CTestTestfile.cmake files are searched recursively and all tests which are 
defined by add_test() within the files are added to the test list.

There are some debug logging lines in the plugin, but I deactivated them for 
now. Unfortunately there is no option-page where you can switch the logging 
on/off (should move that to the top of the feature list). You could get the 
sources from github, enable logging, build your custom version and see what 
message you get.

The changes would be in “CTestExecutor.cs” (line 27) and “CTestDiscoverer.cs” 
(line 29). Change the line

public bool EnableLogging { get; set; } = false;

to

public bool EnableLogging { get; set; } = true;

further comments inline.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nagy-Egri Máté Ferenc 
via CMake
Sent: Thursday, February 04, 2016 3:33 PM
To: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer


Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much 
apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the 
output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

[>] this should be perfectly OK, ctest should take care for itself where to 
find the binaries to execute when testing.

inside my unit-tests’ file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

…

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )

[>] what do you mean by „unit-test file”? Is it just another CMakeLists.txt or 
cmake script in your cmake script tree? or is this some script you run using 
ctest? I am not familiar with the ctest scripting options and I am pretty sure 
this is not supported by the extension right now. It is mainly thought to 
provide the tests which are executed by the RUN_TESTS target within the test 
explorer and allow more comfortable separate test running from within VS.

I have configured my build to use VS2015 Win64 platform. Because the default is 
to look for x86 targets, I changed the default test platform to be x64 within 
VS, but it still won’t find my tests. Could you give some directions what might 
I be doing wrong?

[>] AFAIK you don’t have to switch any

[Az eredeti üzenetnek csak egy része van beillesztve.]
-- 

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

Re: [CMake] CTest integration in Visual Studio TestExplorer

[Stuermer, Michael SP/HZA-ZSEP]

Hi Máté,

thanks for trying the extension!

Some questions before going more into details:

-  do you have a CTestTestfile.cmake in your build root i.e. where 
the.sln file is you have opened with Visual Studio?

-  do you have a RUN_TESTS target/project in your visual studio 
solution? It could be in the “CMakePredefinedTargets” folder…

The basic concept of test discovery for the plugin is, to look for a 
CTestTestfile.cmake file in the same folder where the .sln file is. From there 
all CTestTestfile.cmake files are searched recursively and all tests which are 
defined by add_test() within the files are added to the test list.

There are some debug logging lines in the plugin, but I deactivated them for 
now. Unfortunately there is no option-page where you can switch the logging 
on/off (should move that to the top of the feature list). You could get the 
sources from github, enable logging, build your custom version and see what 
message you get.

The changes would be in “CTestExecutor.cs” (line 27) and “CTestDiscoverer.cs” 
(line 29). Change the line

public bool EnableLogging { get; set; } = false;

to

public bool EnableLogging { get; set; } = true;

further comments inline.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nagy-Egri Máté Ferenc 
via CMake
Sent: Thursday, February 04, 2016 3:33 PM
To: cmake@cmake.org
Subject: Re: [CMake] CTest integration in Visual Studio TestExplorer


Hi Michael,

first of all, let me congratulate you on the integration. Great stuff and much 
apreciated.

I gave your add-in a spin, however it fails to find my unit tests. I set the 
output directory globally in the top-level CMakeLists.txt file as


set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${Build_Root}/bin/${Configuration_Name})

[>] this should be perfectly OK, ctest should take care for itself where to 
find the binaries to execute when testing.

inside my unit-tests’ file I have entries such as

# Adding library target for build
add_executable (STL-Test1-RK4 ${STL_Test1_RK4_BUILD})

…

# Add CTest entry
add_test( ${PROJECT_NAME} ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/STL-Test1-RK4 )

[>] what do you mean by „unit-test file”? Is it just another CMakeLists.txt or 
cmake script in your cmake script tree? or is this some script you run using 
ctest? I am not familiar with the ctest scripting options and I am pretty sure 
this is not supported by the extension right now. It is mainly thought to 
provide the tests which are executed by the RUN_TESTS target within the test 
explorer and allow more comfortable separate test running from within VS.

I have configured my build to use VS2015 Win64 platform. Because the default is 
to look for x86 targets, I changed the default test platform to be x64 within 
VS, but it still won’t find my tests. Could you give some directions what might 
I be doing wrong?

[>] AFAIK you don’t have to switch anything here to discover ctest tests. The 
tests are discovered from the CTestTestfile.cmake files, there is no checking 
for platform or bitness done.


Cheers,
Máté


Feladó: Stuermer, Michael SP/HZA-ZSEP<mailto:michael.stuer...@schaeffler.com>
Elküldve: 2016. január 22., péntek 12:37
Címzett: cmake@cmake.org<mailto:cmake@cmake.org>
Tárgy: [CMake] CTest integration in Visual Studio TestExplorer

Hello everyone,

picking up the line from Tobias from around a year ago I changed a few things 
in the ctest unittest adapter. It now works for both Visual Studio 2013 and 
2015. 2012 is supported in general but I didn't try it (means: I can install 
it). Merging and pull request for original version will follow (as soon as 
there is time), but I would be really happy if some developers from the 
community could comment on the current state and give some feedback.

I tested it so far with the CMake build and tests and discovering and executing 
the whole lot of 400+ tests runs well so far. Let me know what could/should be 
improved.

You can download the latest version of the extension here:

https://github.com/micst/CTestTestAdapter/blob/micst/CTestTestAdapter.vsix

Check the sources on github here:

https://github.com/micst/CTestTestAdapter

best regards,
Michael


-Original Message-
From: Tobias Becker [mailto:becker.t...@gmail.com]
Sent: Saturday, November 22, 2014 11:35 PM
Subject: [CMake] CTest integration in Visual Studio TestExplorer

So I tried my luck with creating an extension for Visual Studio that allows you 
to use the Test Explorer to discover and run your CTests.  You can download it 
in the visual studio gallery. Read about it on 
http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ .

I'd be happy if anyone wanted to give me feedback or contribute on 
https://github.com/toeb/CTestTestAdapter ;)

Sorry for the shameless plug (but hey - its free)


Kind Regards,

Tobias
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://public.kitware.com/pipermail/cmake/attachments/20141122/

[CMake] Setting target property FOLDER on target ALL_BUILD

[Stuermer, Michael SP/HZA-ZSEP]

I would like to move the ALL_BUILD target tot he "CMakePredefinedTargets", 
however this seems not be possible straight away. At least even at the very end 
of the very last CMakeLists.txt I still cannot call

set_target_properties(ALL_BUILD
PROPERTIES
FOLDER " CMakePredefinedTargets ")

without getting an error that the target does not exist. Can it be done at all?

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

Re: [CMake] Setting target property FOLDER on target ALL_BUILD

[Stuermer, Michael SP/HZA-ZSEP]

>From cmGlobalVisualStudioGenerator.cxx (line 92ff):

#if 0
  // Can't activate this code because we want ALL_BUILD
  // selected as the default "startup project" when first
  // opened in Visual Studio... And if it's nested in a
  // folder, then that doesn't happen.
  //
  // Organize in the "predefined targets" folder:
  //
  if (this->UseFolderProperty())
{
allBuild->SetProperty("FOLDER", this->GetPredefinedTargetsFolder());
}
#endif

Ok, this makes it pretty clear. But "we" don't want ALL_BUILD always to be 
selected as default "startup project". How about something like this:

  if (this->UseFolderProperty())
{
const char* prop = this->GetCMakeInstance()->GetState()
  ->GetGlobalProperty("ALL_BUILD_TARGET_FOLDER");
if(prop)
  {
  allBuild->SetProperty("FOLDER", prop);
 }
}

This would allow relocating the ALL_BUILD target, but it must be done 
explicitly using a new global property ALL_BUILD_TARGET_FOLDER.

If it's acceptable I'd submit a patch for this.

best regards,
Michael


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stuermer, Michael 
SP/HZA-ZSEP
Sent: Friday, January 29, 2016 3:43 PM
To: cmake@cmake.org
Subject: [CMake] Setting target property FOLDER on target ALL_BUILD

I would like to move the ALL_BUILD target tot he "CMakePredefinedTargets", 
however this seems not be possible straight away. At least even at the very end 
of the very last CMakeLists.txt I still cannot call

set_target_properties(ALL_BUILD
PROPERTIES
FOLDER " CMakePredefinedTargets ")

without getting an error that the target does not exist. Can it be done at all?

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

[CMake] CTest integration in Visual Studio TestExplorer

[Stuermer, Michael SP/HZA-ZSEP]

Hello everyone,

picking up the line from Tobias from around a year ago I changed a few things 
in the ctest unittest adapter. It now works for both Visual Studio 2013 and 
2015. 2012 is supported in general but I didn't try it (means: I can install 
it). Merging and pull request for original version will follow (as soon as 
there is time), but I would be really happy if some developers from the 
community could comment on the current state and give some feedback.

I tested it so far with the CMake build and tests and discovering and executing 
the whole lot of 400+ tests runs well so far. Let me know what could/should be 
improved.

You can download the latest version of the extension here:

https://github.com/micst/CTestTestAdapter/blob/micst/CTestTestAdapter.vsix

Check the sources on github here:

https://github.com/micst/CTestTestAdapter

best regards,
Michael


-Original Message-
From: Tobias Becker [mailto:becker.t...@gmail.com] 
Sent: Saturday, November 22, 2014 11:35 PM
Subject: [CMake] CTest integration in Visual Studio TestExplorer

So I tried my luck with creating an extension for Visual Studio that allows you 
to use the Test Explorer to discover and run your CTests.  You can download it 
in the visual studio gallery. Read about it on 
http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ .

I'd be happy if anyone wanted to give me feedback or contribute on 
https://github.com/toeb/CTestTestAdapter ;)

Sorry for the shameless plug (but hey - its free)


Kind Regards,

Tobias
-- next part --
An HTML attachment was scrubbed...
URL: 


-- 

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

[CMake] avoid permanent rebuild of custom_target

[Stuermer, Michael SP/HZA-ZSEP]

How can I avoid a custom target to be rebuild everytime I build my solution? I 
added my target like this:

add_custom_target(CopyNugetPackages
DEPENDS ${depends_list}
COMMENT " copying nuget packages "
VERBATIM
)
set_target_properties(CopyNugetPackages PROPERTIES
EXCLUDE_FROM_ALL TRUE
FOLDER "CMakePredefinedTargets")

The variable "depends_list" contains a list of custom_command outputs 
(essentially .dll files which are copied). All the custom commands are actually 
only executed once, but the custom target "CopyNugetPackages" is run over and 
over again.

I would like to run "CopyNugetPackages" only as a dependency from other targets:

add_dependencies(${target} CopyNugetPackages)

So "CopyNugetPackages" should only be built if ${target} is built. How can I do 
this or is it impossible?


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  
·  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.





-- 

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

Re: [cmake-developers] Code style auto-formatting

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

> -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

[Stuermer, Michael SP/HZA-ZSEP]

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

[CMake] Visual Studio variable in include_directories path?

[Stuermer, Michael SP/HZA-ZSEP]

I would like to add a Visual Studio variable such as $(VCInstallDir) to the 
include directories of a target.

include_directories() obviously does not work, as cmake thinks the path is 
relative and the project path is prepended to my initial value.

Any hints how I can do this?

PS: the same with link_directories() and some link paths :(


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  
·  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.




-- 

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

Re: [cmake-developers] C# support status?

[Stuermer, Michael SP/HZA-ZSEP]

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?

[Stuermer, Michael SP/HZA-ZSEP]

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] warn if features used that require cmake-x.y

[Stuermer, Michael SP/HZA-ZSEP]

Have a look at cmake_minimum_required() and cmake_policy(). I think with these 
both it should be possible to verify you are using a cmake version that 
provides all features which are required by your project.

See here:

http://www.cmake.org/cmake/help/v3.3/command/cmake_minimum_required.html?#command:cmake_minimum_required

and here:

http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html

best regards,
Michael


 -Original Message-
 From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nicolas Bock
 Sent: Wednesday, July 01, 2015 8:29 PM
 To: cmake@cmake.org
 Subject: [CMake] warn if features used that require cmake-x.y
 
 Hi,
 
 is there a way to get CMake to warn if a feature is used that requires
 a cmake version greater than some version x.y?
 
 Thanks,
 
 nick
 --
 
 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
-- 

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

Re: [CMake] How to find libraries with custom folder structure

[Stuermer, Michael SP/HZA-ZSEP]

Did you add the directory where your find script is in to the CMAKE_MODULE_PATH?

To verify your script is called, just add a message(executing my module) or 
so on top of your script, this always works very well for me when I'm not sure.

See here for more info about the CMAKE_MODULE_PATH:

http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_MODULE_PATH.html?highlight=cmake_module_path

best regards,
Michael

 -Original Message-
 From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Benedikt
 Führer
 Sent: Wednesday, July 01, 2015 6:28 PM
 To: cmake@cmake.org
 Subject: [CMake] How to find libraries with custom folder structure
 
 Hi,
 
 my jpeg-6b is located in the following folder structure:
 
 \libs
 --\jpeg-6b
 \include
 \lib
 --\x64
 \debug
 \release
 
 How can I find the needed files here? The standard FindJPEG in the
 CMake folder seems to expect a different folder structure and so
 doesn't find all components. I've tried to write a custom FindJPEG but
 it seems like it always prefers the standard FindJPEG over my custom
 one. Do I have to put it into a specific location? The current folder
 is definitely known to my CMake scripts because I have other script
 files which are correctly loaded from there.
 
 Thanks
 --
 
 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
-- 

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

Re: [cmake-developers] C# support?

[Stuermer, Michael SP/HZA-ZSEP]

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?

[Stuermer, Michael SP/HZA-ZSEP]

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] C# support?

[Stuermer, Michael SP/HZA-ZSEP]

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

[cmake-developers] C# support?

[Stuermer, Michael SP/HZA-ZSEP]

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?

[Stuermer, Michael SP/HZA-ZSEP]

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?

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

 -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

[Stuermer, Michael SP/HZA-ZSEP]

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

[Stuermer, Michael SP/HZA-ZSEP]

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