[cmake-developers] patch VS2010 generator : handle VS_GLOBAL_RootNamespace as well as VS_GLOBAL_ROOTNAMESPACE

2016-07-20 Thread Benjamin Ballet via cmake-developers 
Hi folks,

As user I'm currently working on migrating C++CLI projects to CMake.

I wasted a few hours because I used VS_GLOBAL_RootNamespace (a specialized
version of VS_GLOBAL_ property) instead of
VS_GLOBAL_ROOTNAMESPACE.

So here is a patch to save the next one from wasting those same hours.

In my opinion, VS_GLOBAL_ROOTNAMESPACE with VS_GLOBAL_PROJECT_TYPE and
VS_GLOBAL_KEYWORD should be tagged as deprecated and users should be
redirected to VS_GLOBAL_. It would be simpler.


-- 
*Benjamin BALLET*
Ingénieur R

*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* :  01 44 69 37 37
*>* www.activisu.com


0001-VisualStudio10-generator-the-RootNamespace-property-.patch
Description: Binary data
-- 

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 v4] For consoles output on Windows use our own std::streambuf

2016-07-20 Thread Brad King 
On 07/09/2016 10:12 PM, Dāvis Mosāns wrote:
>  int main(int ac, char const* const* av)
>  {
> +#if defined(_WIN32)
> +  // Replace streambuf so we can output Unicode to console
> +  cmsys::ConsoleBuf *cbufio = CM_NULLPTR;
> +  cmsys::ConsoleBuf *cbuferr = CM_NULLPTR;
> +  std::streambuf *coutbuf = std::cout.rdbuf();
> +  std::streambuf *cerrbuf = std::cerr.rdbuf();
> +  try {
> +cbufio = new cmsys::ConsoleBuf();
> +coutbuf = std::cout.rdbuf(cbufio);
> +cbuferr = new cmsys::ConsoleBuf(true);
> +cerrbuf = std::cerr.rdbuf(cbuferr);
> +  } catch (const std::runtime_error& ex) {
> +std::cerr << "Failed to create ConsoleBuf!" << std::endl
> +  << ex.what() << std::endl;
> +  };
> +#endif
...
> +#if defined(_WIN32)
> +  if (cbufio) {
> +delete cbufio;
> +std::cout.rdbuf(coutbuf);
> +  }
> +  if (cbuferr) {
> +delete cbuferr;
> +std::cerr.rdbuf(cerrbuf);
> +  }
> +#endif

Please add to KWSys ConsoleBuf a RAII-style helper to perform
the above steps.  Its constructor can take either std::cout
or std:cerr by reference.

Also, please add a test case for this to KWSys itself.  The
test should at least be able to compile and run.  Verification
that output looks right may need to be a manual step though.

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] [PATCH v4 2/4] Deprecate const char* SystemTools::GetEnv function

2016-07-20 Thread Brad King 
On 07/07/2016 05:54 PM, Dāvis Mosāns wrote:
>  Source/kwsys/SystemTools.hxx.in | 14 --

Thanks.  Applied to KWSys first:

 http://review.source.kitware.com/21348

-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 v5 2/2] Add MinGW support for FStream

2016-07-20 Thread Brad King 
On 07/18/2016 09:28 AM, Brad King wrote:
> Thanks.  I've added this and its parent commit to KWSys:
> 
>  http://review.source.kitware.com/21339

This is now in KWSys `master`.  I've updated it in CMake:

 KWSys 2016-07-19 (9d1dbd95)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ef2b2b1

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] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too

2016-07-20 Thread Brad King 
On 07/06/2016 03:12 PM, Dāvis Mosāns wrote:
> Otherwise it would use POSIX functions which works only for ASCII paths.

Thanks.  Applied to KWSys first with minor tweaks:

 http://review.source.kitware.com/21349

-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 v4 3/4] Use SystemTools::GetEnv and HasEnv functions

2016-07-20 Thread Brad King 
On 07/18/2016 10:00 AM, Brad King wrote:
> On 07/07/2016 05:54 PM, Dāvis Mosāns wrote:
>>  Source/kwsys/SystemTools.cxx| 38 
>> +++--
>>  Source/kwsys/testSystemTools.cxx|  9 ---
> 
> Applied to upstream KWSys first:
> 
>  http://review.source.kitware.com/21340

This is now in KWSys `master`.  I've updated it in CMake:

 KWSys 2016-07-18 (19732229)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb7b5087

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] Security Report for CMake

2016-07-20 Thread Brad King 
On 07/20/2016 02:31 AM, Justin Clift wrote:
> Amir pointed out there may be other locations with the same
> unquoted path problem in the template.

Thanks.  I'm not very familiar with NSIS or the syntax in the
template file so we'll be dependent on others to find/fix any
remaining problems.

Meanwhile I've revised the commit message to update the credits:

 NSIS: Quote uninstaller path when executing it in a shell
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=057f21ae

I've queued this for merge to 'release' for 3.6.1.

-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] Improved WIX support

2016-07-20 Thread 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

Re: [cmake-developers] Improved WIX support

2016-07-20 Thread Nils Gladitz 

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?


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

Re: [cmake-developers] Security Report for CMake

2016-07-20 Thread Justin Clift 
On 19 Jul 2016, at 21:29, Brad King  wrote:
> On 07/19/2016 01:46 PM, Cyril VALLICARI wrote:
>> Here a Patch that correct the vulnerability 
> 
> Thanks, applied:
> 
> NSIS: Quote uninstaller path when executing it in a shell
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01e1f694
> 
> -Brad

Oops, it kind of looks like Cyril forgot to mention there could
be further problems in the same template file.  The initial line
was pointed out by Amir Szekely (NSIS project) as below, while we
were trying to figure out where the unquoted path problem in
sqlitebrowser's package was coming from. ;)

Amir pointed out there may be other locations with the same
unquoted path problem in the template.

In my testing for a solution for sqlitebrowser's package, the
one I fixed was definitely an issue, easily replicated.

I'm not sure where the unquoted registry string would be used from.
It didn't seem to be used as such from Windows Control Panel ->
Add/Remove Programs.  So, I ignored it. ;)

I don't know enough about CPack to know what other bits I may have
missed though, nor if that unquoted string in the registry could be
a problem in some other way.

Thoughts? :)

Regards and best wishes,

Justin Clift


Begin forwarded message:
> From: Amir Szekely 
> Subject: Re: Security report for NSIS
> Date: 15 July 2016 01:33:12 BST
> To: Cyril VALLICARI , jus...@postgresql.org
> 
> This seems to be a bug in CPack:
> 
> https://github.com/Kitware/CMake/blob/master/Modules/NSIS.template.in#L916
> 
> That's the line where it executes the uninstaller without quotes. There may 
> be more than one place.
> 
> They are also writing an unquoted string to to the registry:
> 
> https://github.com/Kitware/CMake/blob/master/Modules/NSIS.template.in#L655
> 
> For a quick fix, you can turn off CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL.
[snip]

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

-- 

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