Re: [cmake-developers] FastBuild Generator

2016-10-10 Thread Brad King
On 10/10/2016 09:39 AM, Charles Huet wrote:
> * the test CMake.CheckSourceTree does not work with Fastbuild,
>   but I could not get it to work with Ninja either, maybe I
>   have an environment problem ?

It works with Ninja for me.  Are you building CMake out-of-source?

> * the test SimpleInstall requires the build tool to be able to
>   run multiple instances in the same hierarchy, which Fastbuild
>   does not support.

I don't understand what you mean.

> * It seems SimpleInstall-Stage2 depends upon SimpleInstall,
>   is this right ?

Yes.

-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] FastBuild Generator

2016-10-10 Thread Charles Huet
Hi again.

I performed all the aforementioned actions, please check everything is OK
for you.

I have a few questions:
* the test CMake.CheckSourceTree does not work with Fastbuild, but I could
not get it to work with Ninja either, maybe I have an environment problem ?
* the test SimpleInstall requires trhe build tool to be able to run
multiple instances in the same hierarchy, which Fastbuild does not support.
Should I refactor the test to remove this requirement ? Or simply ignore
the test ?
* It seems SimpleInstall-Stage2 depends upon SimpleInstall, is this right ?

The branch I recently pushed has only a few tests failing, quite a few seem
to be related to a lack of non-source file dependencies as far as I can
tell.

Thanks.

Le jeu. 6 oct. 2016 à 19:33, Charles Huet  a écrit :

> >* Please use Utilities/Scripts/clang-format.bash for
> >  code style.  This is easy to apply automatically later
> >  so don't worry about it too much.
> I'll get on this soon, I like to have proper style.
>
>
> > * For final integration I'd like the commits to be squashed
>
> >  and arranged in an organized way.  This is hard to do until
> >  you have everything working though.
>
> Sure. For now there are the first few commits which I can't change much to
> keep proper attribuation, and a few commits on top which will be squashed
> together once the dev is complete (or maybe earlier if I feel like it).
>
> >* Please update the license notices to use the new style that
> >  we switched to in `master`.  Both C++ and .cmake notices
> >  changed.
> Will do.
>
> Le jeu. 6 oct. 2016 à 17:32, Brad King  a écrit :
>
> On 10/06/2016 08:32 AM, Charles Huet wrote:
> > Do you think it is time to start the review, or should it wait
> > until I have 100% of the tests passing ?
>
> Thanks for the update.  Generally my reviews for new features
> mostly look at documentation, tests, style, etc. rather than
> at implementation details (which can easily be fixed/changed
> later).  Therefore final review and integration should not start
> until everything is working.
>
> However, I'm happy to take quick glances at progress once in
> a while.  Here are some comments from the current version:
>
> * Please use Utilities/Scripts/clang-format.bash for
>   code style.  This is easy to apply automatically later
>   so don't worry about it too much.
>
> * For final integration I'd like the commits to be squashed
>   and arranged in an organized way.  This is hard to do until
>   you have everything working though.
>
> * Please update the license notices to use the new style that
>   we switched to in `master`.  Both C++ and .cmake notices
>   changed.
>
> 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: Don't emit warning when config file not found

2016-10-10 Thread Brad King
On 10/09/2016 03:24 PM, Christoph Grüninger wrote:
> * or loosing the output of tests and feature summary, as both tests are QUIET.
> 
> I'd prefer to write the error message to the CMakeError.log and reduce
> the output to one line. I think, the current behavior must be considered
> a bug.

The default behavior evolved over many years to satisfy many use cases and
give people the information they need to resolve real problems.  It is not
going to change.  However, if you'd like to propose additional options to
these interfaces to get the behavior you want then that would be fine.
Perhaps find_package could gain an ``OPTIONAL`` switch.  I'm not very
familiar with feature_summary so I'm not sure what that would need off the
top of my head.

-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