Thank you
On Tue, Sep 6, 2016 at 3:24 PM, Brad King wrote:
> On 09/06/2016 03:00 PM, Ben Keller wrote:
>> The workaround we are using for this currently is to compile a
>> modified version of cmake that appends the following cmake code below
>> the get_filename_component
On 30/08/2016 14:53, Brad King wrote:
On 08/28/2016 01:51 PM, Roger Leigh wrote:
The macro name might need adjusting
The idea looks fine to me. Typically we name module-provided APIs with
the module name. How about "GNUInstallDirs_get_absolute_install_dir"?
I'm also open to other
Ok, thanks Brad
On 5 September 2016 at 22:42, Brad King wrote:
> On 09/05/2016 04:22 AM, Steve Lorimer wrote:
> > $ cat src/foo/foobar/CMakeLists.txt
> > add_executable(foobar main.cpp)
> > However, if I am in the build/foo directory, then nothing happens
> > if I "make
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
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
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
On 09/05/2016 04:39 PM, Cristian Adam wrote:
> On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote:
>> Something goes wrong with finding some of the symbols in it,
>> such as some from `json_value.cpp`.
>
> $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a
> json_reader.cpp.o
> json_value.cpp.o
>
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
On 09/06/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:
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.
Thanks. I modified the patch to work without the global/public
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
> -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:
>
>
> -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
On 09/06/2016 03:45 PM, Nils Gladitz wrote:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf10d99ff9b3d8f68919164fcf8
Please verify that I haven't broken anything.
I broke writing of WIX include files. Should be fixed now:
On 06.09.2016 17:19, Stuermer, Michael SP/HZA-ZSEP wrote:
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.
Thanks I reformatted, squashed and merged to "next" for
On 06-Sep-16 14:26, Brad King wrote:
On 09/05/2016 04:39 PM, Cristian Adam wrote:
On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote:
Something goes wrong with finding some of the symbols in it,
such as some from `json_value.cpp`.
$ ar t Utilities/cmjsoncpp/libcmjsoncpp.a
json_reader.cpp.o
On 09/06/2016 02:39 PM, Cristian Adam wrote:
> Who should have noticed that the two object files were empty and try a
> new compilation? CMake or make?
Nothing. This is not a failure case that we expect to be handled.
The .o files exist with a timestamp newer than their dependencies,
so the
CMake version 3.5.0
When exporting from a project (with install(EXPORT ...)),
theTargets.cmake file contains logic for computing the
_IMPORT_PREFIX. This _IMPORT_PREFIX is then used in the
Targets-.cmake file to generate the
IMPORTED_LOCATION_. The generation appears to
be accomplished by
On 09/06/2016 03:00 PM, Ben Keller wrote:
> The workaround we are using for this currently is to compile a
> modified version of cmake that appends the following cmake code below
> the get_filename_component stanza in Targets.cmake:
>
> if("${_IMPORT_PREFIX}" STREQUAL "/")
> set(_IMPORT_PREFIX
18 matches
Mail list logo