Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets

2015-12-04 Thread Brad King 
On 12/03/2015 07:11 PM, Roger Leigh wrote:
> I hope this is now staged correctly for review.  I've pushed a 
> tiff-imported-target topic branch and merged into next:

Yes, thanks.  I've just updated a nightly build client to enable
the test for this.

-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] Add command line options for deprecation message control

2015-12-04 Thread Brad King 
On 12/04/2015 10:05 AM, Michael Scott wrote:
> The build tree is selected by changing the source directory setting in 
> the GUI right?

Actually when one choose a build tree it will locate the corresponding
source tree automatically if both exist.  Selecting the source tree
may be followed by creating a new build tree so that direction does
not happen automatically IIRC.

> Adding in one toggle would be fine, but I imagine that when we come to 
> adding support for upgrading warnings to errors, the additional two 
> checkboxes would be a bit much. I was thinking of perhaps instead having 
> just one entry in the options menu, which opens up a sub-window which 
> contains the group of message related options.

Yes.  Please move the -Wdev options there too.  Actually since it is
a property of the build tree selected and not of the overall session,
perhaps the button for these settings should not be in the menu but
in the dialog box somewhere below.

Thanks,
-Brad

P.S.  Your mailer broke the thread again.

-- 

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] Extend copy and copy_if_different commands with support multiple files

2015-12-04 Thread Brad King 
On 12/04/2015 09:18 AM, Bartosz Kosiorek wrote:
> Finally I manage to add wildcard support.
> I have taken SimpleGlob.h library from:
> https://github.com/brofield/simpleopt

We don't want to do wildcard expansion in CMake commands.  We want to leave
it up to the shell to expand wildcards on the command line, or have explicit
file(GLOB) commands in CMake script code.

I've applied the patches from the previous post, with a slightly
different breakdown and some fixes to the test:

 cmake: Improve '-E' help message formatting
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be5020b

 cmake: Teach -E copy[_if_different] to support multiple files (#15703)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=384ae551

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] Add command line options for deprecation message control

2015-12-04 Thread Michael Scott 

Let's start with the toggle because that will make cmake-gui able
to set the option just like the command line.

Sounds good, that's what I was thinking as well.


Also I'm not sure what to do about persistence of the option check
boxes in cmake-gui when selecting a different build tree.  As a user
I may expect those options to be loaded from the current cache in each
build tree I select.
The build tree is selected by changing the source directory setting in 
the GUI right? So it should get the state of the checkboxes based on the 
cache whenever this changes.


Adding in one toggle would be fine, but I imagine that when we come to 
adding support for upgrading warnings to errors, the additional two 
checkboxes would be a bit much. I was thinking of perhaps instead having 
just one entry in the options menu, which opens up a sub-window which 
contains the group of message related options.


Cheers,
Michale

--

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] Add command line options for deprecation message control

2015-12-04 Thread Michael Scott 

Actually when one choose a build tree it will locate the corresponding
source tree automatically if both exist.  Selecting the source tree
may be followed by creating a new build tree so that direction does
not happen automatically IIRC.
Okay, I'm not too familiar with the GUI, how do you choose a build tree? 
So that I can look at where I can hook in the message cache detection.



Your mailer broke the thread again.

Sorry, this one shouldn't break the thread.


Cheers,
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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers 
With Visual Studio, you definitely **need** separate pch for each CONFIG.
Every pch is going to include headers which have Debug/Release differences
in them, and it is not safe to mix and match compiler output from separate
configs together.


D


On Friday, December 4, 2015, Daniel Pfeifer  wrote:

> My working branch is here:
> https://github.com/purpleKarrot/CMake/commits/pch
>
> Feel free to comment, evaluate, contribute.
>
> I am nut fully decided regarding these two questions:
> - Do we want to support different pch per CONFIG? I think no, but I
> might be wrong.
> - Do we want to support different pch per LANGUAGE? I first thought
> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 5:12 AM, Taylor Braun-Jones
> > wrote:
> > Perhaps the Paris Climate talks would be good inspiration for tackling
> > this feature. How many pounds of CO2 are emitted each year due to
> > needless header compilation CPU cycles? :-)
> >
> > On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
> > > wrote:
> >>> -Original Message-
> >>
> >>> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org
> ]
> >>
> >>> On Behalf Of Daniel Pfeifer
> >>
> >>> Sent: Wednesday, October 28, 2015 08:57
> >>
> >>> To: Taylor Braun-Jones
> >>
> >>> Cc: CMake Developers
> >>
> >>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support
> >>
> >>> and custom compiler based implementation
> >>
> >>>
> >>
> >>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones  >>
> >>> jones.org> wrote:
> >>
> >>> > What's the status of this PCH feature? Does it need testers? More
> >>
> >>> > design input? I'd love to see this feature in a future CMake release.
> >>
> >>> > Willing to help.
> >>
> >>>
> >>
> >>> I haven't worked on it for quite some time as I currently don't have a
> >>
> >> project
> >>
> >>> which needs it.
> >>
> >>> But I agree that we should get it into CMake, even if it does not
> >>
> >>> support
> >>
> >> all
> >>
> >>> generators yet.
> >>
> >>> Support for additional generators can be added successively.
> >>
> >>>
> >>
> >>> I will rebase my branch to master on the weekend, ie port it to
> >>
> >>> cmGeneratorTarget.
> >>
> >>> Then you are free to help with review, testing, and additional
> generators.
> >>
> >>>
> >>
> >>> Which generators are the most important for you?
> >>
> >>
> >>
> >> I'd also love to see some progress on PCH support, though I haven't had
> much
> >> time recently... I'd be quite happy to test however with the below
> compilers
> >> and generators - all of which we would use PCH support with:
> >>
> >>
> >>
> >> Generators:
> >>
> >>
> >>
> >> * Ninja
> >>
> >> * Visual Studio 2008 (eventually 2015)
> >>
> >> * Although we're not currently using it, CMake would be pretty broken
> >> without supporting: Unix Makefiles
> >>
> >>
> >>
> >> Compilers:
> >>
> >>
> >>
> >> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
> >>
> >> * Embarcadero bcc32 compiler: Ninja
> >>
> >> * GCC: Ninja
> >>
> >>
> >>
> >> Best regards,
> >>
> >>
> >>
> >> James Johnston
> >>
> >>
> >> --
> >>
> >> 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. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting:

Re: [cmake-developers] Add command line options for deprecation message control

2015-12-04 Thread Brad King 
On 12/03/2015 05:56 PM, Michael Scott wrote:
>> Thanks.  Applied with minor tweaks and merged to 'next' for testing:
> 
> That's great, thanks. Now that the patches are in, would you say it's 
> better to work on adding a deprecated toggle option to the cmake-gui, or 
> to work on adding support for upgrading warnings to errors?

Let's start with the toggle because that will make cmake-gui able
to set the option just like the command line.  Note that as part
of integrating your changes I changed the CMAKE_WARN_DEPRECATED
cache entry to INTERNAL instead of BOOL so it won't show up in
the cmake-gui.  Therefore a dedicated switch would be useful.

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread Daniel Pfeifer 
> On Friday, December 4, 2015, Daniel Pfeifer  wrote:
>>
>> My working branch is here:
>> https://github.com/purpleKarrot/CMake/commits/pch
>>
>> Feel free to comment, evaluate, contribute.
>>
>> I am nut fully decided regarding these two questions:
>> - Do we want to support different pch per CONFIG? I think no, but I
>> might be wrong.
>> - Do we want to support different pch per LANGUAGE? I first thought
>> yes, but I am no longer certain about that.

On Fri, Dec 4, 2015 at 2:42 PM, David Cole  wrote:
> With Visual Studio, you definitely **need** separate pch for each CONFIG.
> Every pch is going to include headers which have Debug/Release differences
> in them, and it is not safe to mix and match compiler output from separate
> configs together.

Maybe we are confusing two things here.

Visual Studio compiles a pch-binary for each configuration. That
pch-binary is probably incompatible with other configurations.
In my current implementation, the header file that is used to compile
the pch-binary is generated by CMake, using information provided by
the user.

This approach is very powerful, as it supports usage requirements. See
here for an example:
You can see here:
https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt

My question actually boils down to whether CMake should
(a) generate a header file for each configuration/language, or
(b) generate a **single** header file which is then precompiled for
all configurations/languages.

Both approaches are possible, because we can use #ifdef __cplusplus etc.

More importantly: Do we want the user to
(c) tell CMake about different headers-to-be-precompiled per
config/language so CMake can write the appropriate #ifdefs into the
generated file, or
(d) put #ifdefs into the provided file so that CMake can #include it
in the generated file without any additional logic?

Again both approaches are technically possible. It is not about what
we **need**, but what we **want**. And there, I am undecided.
-- 

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] Add command line options for deprecation message control

2015-12-04 Thread Brad King 
On 12/04/2015 10:52 AM, Michael Scott wrote:
>> Actually when one choose a build tree it will locate the corresponding
>> source tree automatically if both exist.  Selecting the source tree
>> may be followed by creating a new build tree so that direction does
>> not happen automatically IIRC.
> Okay, I'm not too familiar with the GUI, how do you choose a build tree? 
> So that I can look at where I can hook in the message cache detection.

There are two directory fields:

 "Where is the source code:"

 "Where to build the binaries:"

The latter is the build tree selection.

>> Your mailer broke the thread again.
> Sorry, this one shouldn't break the thread.

It did.

-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] Extend copy and copy_if_different commands with support multiple files

2015-12-04 Thread Bartosz Kosiorek 
Thanks Brad.

Unfortunately we cannot use file(GLOB), because it is executed during
generate step,
and we would like to copy files which is created during Build step.

Currently for filtering these files, we are using "cmake -E tar" to filter
these files (so it packing and upacking).
I think it is awful solution, but I cannot find better.
What would you propose in that case?

Is it possible to introduce "cmake -E list" command with wildcard support,
to be able to filter files/directories, during Build step?
The we couid use it to "cmake -E copy" command

Best Regards
Bartosz


2015-12-04 16:35 GMT+01:00 Brad King :

> On 12/04/2015 09:18 AM, Bartosz Kosiorek wrote:
> > Finally I manage to add wildcard support.
> > I have taken SimpleGlob.h library from:
> > https://github.com/brofield/simpleopt
>
> We don't want to do wildcard expansion in CMake commands.  We want to leave
> it up to the shell to expand wildcards on the command line, or have
> explicit
> file(GLOB) commands in CMake script code.
>
> I've applied the patches from the previous post, with a slightly
> different breakdown and some fixes to the test:
>
>  cmake: Improve '-E' help message formatting
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0be5020b
>
>  cmake: Teach -E copy[_if_different] to support multiple files (#15703)
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=384ae551
>
> 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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers 
Right, I was talking about the pch-binary.

Why would CMake even need to generate a header file for pre-compiled
headers? Why not just allow the user to say which of his header files
should be the one to use for precompiled headers?

I have a project I work on which is a VS-only non-CMake based project,
where we name the pch input header files as "${libraryName}PCH.h" and
anything we want included in the pch-binary we can just add to that
file.

Personally, I would prefer to have a manually edited file as the input
to precompiled header so I can add whatever I want in there.

What would be in the contents of the generated header? How do you know
how much or how little is reasonable to put in there? Seems like a
per-library / per-project sort of decision.


D



On Fri, Dec 4, 2015 at 12:26 PM, Daniel Pfeifer  wrote:
>> On Friday, December 4, 2015, Daniel Pfeifer  wrote:
>>>
>>> My working branch is here:
>>> https://github.com/purpleKarrot/CMake/commits/pch
>>>
>>> Feel free to comment, evaluate, contribute.
>>>
>>> I am nut fully decided regarding these two questions:
>>> - Do we want to support different pch per CONFIG? I think no, but I
>>> might be wrong.
>>> - Do we want to support different pch per LANGUAGE? I first thought
>>> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 2:42 PM, David Cole  wrote:
>> With Visual Studio, you definitely **need** separate pch for each CONFIG.
>> Every pch is going to include headers which have Debug/Release differences
>> in them, and it is not safe to mix and match compiler output from separate
>> configs together.
>
> Maybe we are confusing two things here.
>
> Visual Studio compiles a pch-binary for each configuration. That
> pch-binary is probably incompatible with other configurations.
> In my current implementation, the header file that is used to compile
> the pch-binary is generated by CMake, using information provided by
> the user.
>
> This approach is very powerful, as it supports usage requirements. See
> here for an example:
> You can see here:
> https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt
>
> My question actually boils down to whether CMake should
> (a) generate a header file for each configuration/language, or
> (b) generate a **single** header file which is then precompiled for
> all configurations/languages.
>
> Both approaches are possible, because we can use #ifdef __cplusplus etc.
>
> More importantly: Do we want the user to
> (c) tell CMake about different headers-to-be-precompiled per
> config/language so CMake can write the appropriate #ifdefs into the
> generated file, or
> (d) put #ifdefs into the provided file so that CMake can #include it
> in the generated file without any additional logic?
>
> Again both approaches are technically possible. It is not about what
> we **need**, but what we **want**. And there, I am undecided.
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread Daniel Pfeifer 
On Fri, Dec 4, 2015 at 9:19 PM, David Cole  wrote:
> Right, I was talking about the pch-binary.
>
> Why would CMake even need to generate a header file for pre-compiled
> headers? Why not just allow the user to say which of his header files
> should be the one to use for precompiled headers?

Generating a header file is necessary for two reasons:

1. In GCC, the compiled pch-binary has to be located in the same
directory as the pch-source header. For out-of-source-builds, we
certainly do not want to clutter the source directory, so we need a
header file inside the binary directory. We could create a copy
(fragile), a symlink (not portable), or a forward-#include
(preferred).

2. There can be only one pch per target. See below.

> I have a project I work on which is a VS-only non-CMake based project,
> where we name the pch input header files as "${libraryName}PCH.h" and
> anything we want included in the pch-binary we can just add to that
> file.
>
> Personally, I would prefer to have a manually edited file as the input
> to precompiled header so I can add whatever I want in there.

That is perfectly reasonable. This is also the reason why I think the
config/language specific differences should **not** be handled by
CMake, but by the user.

> What would be in the contents of the generated header? How do you know
> how much or how little is reasonable to put in there? Seems like a
> per-library / per-project sort of decision.

If you look at the example I referred to, there is a library `foo`
with a pch `foo.h` as a usage requirement. There is also an interface
library `bar` with a pch `bar.h` as a usage requirement. Then there is
an executable `foobar` which links against both `foo` and bar`. So the
generated pch-source for the `foobar` target will contain:


/* This file is generated by CMake */
#include 
#include 


Making sense?
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread Daniel Pfeifer 
On Fri, Dec 4, 2015 at 11:32 PM, David Cole  wrote:
> Makes sense.
>
> Can I inject my own "#include " into
> the generated stream, or otherwise inject something into it?

You should be able to do:

target_include_directories(your_target
  PUBLIC public
  PRIVATE private
  )
target_precompile_headers(your_target
  PUBLIC
public_header1.h
public_header2.h
  PRIVATE
private_header1.h
private_header2.h
  )

Does that answer your question? Do you think this could solve your use-case?

> Specifically, for me, I want to include some, but not ALL VTK headers
> for a VTK-based project.

I don't see a problem for that.

> Thanks for working on this.

You are welcome. :-)

> Let me know if you want me to be a Visual Studio tester for you.

Yes, please. My main working environment is Linux. I appreciate any
feedback from different platforms.
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

2015-12-04 Thread David Cole via cmake-developers 
Makes sense.

Can I inject my own "#include " into
the generated stream, or otherwise inject something into it?

Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.

Thanks for working on this.

Let me know if you want me to be a Visual Studio tester for you.


D



On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer  wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole  wrote:
>> Right, I was talking about the pch-binary.
>>
>> Why would CMake even need to generate a header file for pre-compiled
>> headers? Why not just allow the user to say which of his header files
>> should be the one to use for precompiled headers?
>
> Generating a header file is necessary for two reasons:
>
> 1. In GCC, the compiled pch-binary has to be located in the same
> directory as the pch-source header. For out-of-source-builds, we
> certainly do not want to clutter the source directory, so we need a
> header file inside the binary directory. We could create a copy
> (fragile), a symlink (not portable), or a forward-#include
> (preferred).
>
> 2. There can be only one pch per target. See below.
>
>> I have a project I work on which is a VS-only non-CMake based project,
>> where we name the pch input header files as "${libraryName}PCH.h" and
>> anything we want included in the pch-binary we can just add to that
>> file.
>>
>> Personally, I would prefer to have a manually edited file as the input
>> to precompiled header so I can add whatever I want in there.
>
> That is perfectly reasonable. This is also the reason why I think the
> config/language specific differences should **not** be handled by
> CMake, but by the user.
>
>> What would be in the contents of the generated header? How do you know
>> how much or how little is reasonable to put in there? Seems like a
>> per-library / per-project sort of decision.
>
> If you look at the example I referred to, there is a library `foo`
> with a pch `foo.h` as a usage requirement. There is also an interface
> library `bar` with a pch `bar.h` as a usage requirement. Then there is
> an executable `foobar` which links against both `foo` and bar`. So the
> generated pch-source for the `foobar` target will contain:
>
> 
> /* This file is generated by CMake */
> #include 
> #include 
> 
>
> Making sense?
-- 

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] Extend copy and copy_if_different commands with support multiple files

2015-12-04 Thread Brad King 
On 12/04/2015 11:15 AM, Bartosz Kosiorek wrote:
> we cannot use file(GLOB), because it is executed during generate step,
> and we would like to copy files which is created during Build step.

The custom commands always execute inside a shell that can do
glob expansion.

Alternatively, use a "cmake -P myscript.cmake" to script the copy
with e.g. file(COPY) optionally with file(GLOB).

Generally we don't recommend globbing because it can accidentally
get stale files.  If you are creating files during the build step,
don't you know what files are being created?

-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