On 03/11/14 16:02, Brad King wrote:
> My only nitpick is that the work was spread out over so long
> that the author dates are a little confusing. Please reset
> them and then merge to 'next'.
Done. Thanks!
Daniele
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMa
On 11/03/2014 09:07 AM, Daniele E. Domenichelli wrote:
> Can you please review the topic again?
Thanks for updating the topic. The revised topic looks ready
for testing in 'next' to me.
My only nitpick is that the work was spread out over so long
that the author dates are a little confusing. Pl
Hello,
Sorry for resuming an old thread, you can read the original thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8680/
This topic was reviewed and merged into next, but there were some issues
in the unit tests with Ninja and with parallel builds.
I finally found
On 12/20/2013 10:31 AM, Brad King wrote:
> On 12/20/2013 10:08 AM, Daniele E. Domenichelli wrote:
>> As I said, I think this is a corner case, and the changes don't break
>> backwards compatibility
>
> Perhaps *this* change doesn't break anything, but by changing the test
> code to something diffe
On 12/20/2013 10:08 AM, Daniele E. Domenichelli wrote:
> As I said, I think this is a corner case, and the changes don't break
> backwards compatibility
Perhaps *this* change doesn't break anything, but by changing the test
code to something different then we won't know if future changes happen
to
On 20/12/13 14:35, David Cole wrote:
> Existing calls to ExternalProject_Add must continue to work as they
> were before your topic. As long as you leave *most* of them alone for
> testing purposes, you should be ok. Ideally, for new functionality you
> would write a new part of the test, with n
On 12/20/2013 08:35 AM, David Cole wrote:
>> Is it ok for you if I use the same topic and to update the unit tests
> to
>> call it, so that this function is tested as well, even though this
> means
>> updating the existing calls to ExternalProject_Add?
>
> i.e. -- don't let a backwards compatibi
ExternalProject_Add_Step_Dependencies
?
Ok for the name...
Is it ok for you if I use the same topic and to update the unit tests
to
call it, so that this function is tested as well, even though this
means
updating the existing calls to ExternalProject_Add?
Existing calls to ExternalPr
On 18/12/13 17:52, Brad King wrote:
>> Maybe adding a function
>> ExternalProject_Add_Dependencies(name step targets)
>> that internally calls both add_dependencies and add_custom_command(APPEND)?
>
> Yes, I think that makes sense. Perhaps
>
> ExternalProject_Add_Step_Dependencies
>
> ?
Ok
On 12/16/2013 09:23 AM, Daniele E. Domenichelli wrote:
> After some tests I managed to reproduce the behaviour in this test that
> fails, both with ninja (always) and with make -j2 (only sometimes), but
> I'm no longer sure if this is a bug or not.
[snip]
> The problem seems to be that the file le
On 09/12/13 16:06, Brad King wrote:
> Can you reproduce the dependency ordering failure with a few simple
> add_custom_command and add_custom_target calls and no ExternalProject
> module? That will make it much easier to pin down, and the result
> can be added to the general test suite (e.g. Custo
On 12/09/2013 07:51 AM, Daniele E. Domenichelli wrote:
> And then adding an explicit dependency for each project that requires it
>
> add_dependency(${proj}-download SetupLocalXXXRepository)
...but again this requires the existing cases to be modified and
no longer tests that they work without
On 05/12/13 15:00, Brad King wrote:
> However, I do not like having to update all the existing calls
I'm trying to fix this, but I'm having some issues with ninja, and I
don't know anything about...
Instead of using
> +set_property(DIRECTORY PROPERTY EP_INDEPENDENT_STEP_TARGETS update)
> +INDEPE
On 12/06/2013 01:32 PM, Brad King wrote:
> The RunCMake.ExternalProject test failed almost everywhere last
> night and still fails on every continuous. Please take a look.
Thanks for that fix. In order to untangle the topic from the
conflict with CMakeParseArguments_EmptyArgs I reverted both
top
On 12/04/2013 10:41 AM, Brad King wrote:
> On 12/04/2013 07:22 AM, Daniele E. Domenichelli wrote:
>> Done and merged to next again.
>
> Now the ExternalProject tests fail on the continuous builds.
> Please take a look.
The RunCMake.ExternalProject test failed almost everywhere last
night and stil
On 12/04/2013 10:41 AM, Brad King wrote:
> On 12/04/2013 07:22 AM, Daniele E. Domenichelli wrote:
>> Done and merged to next again.
>
> Now the ExternalProject tests fail on the continuous builds.
> Please take a look.
Thanks for the fixes this morning. However, I do not like having
to update al
On 12/04/2013 07:22 AM, Daniele E. Domenichelli wrote:
> Done and merged to next again.
Now the ExternalProject tests fail on the continuous builds.
Please take a look.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/ope
On 02/12/13 18:06, Brad King wrote:
> Please extend the topic with updates to the test suite to cover the
> new option.
> [...]
> Also please add a RunCMake.ExternalProject test with a case to
> verify that this message appears:
> [...]
> Also remove extra indentation from the above-quoted line.
On 11/27/2013 10:40 AM, Brad King wrote:
> Go ahead and merge it to 'next' for testing. I will review it
> there when I return from vacation next week.
Please extend the topic with updates to the test suite to cover the
new option. Even if it is too hard to test that the independent
build behavi
On 11/27/2013 9:51 AM, Daniele E. Domenichelli wrote:
> Any other comment on this topic?
> Can I go on and merge it to next?
Go ahead and merge it to 'next' for testing. I will review it
there when I return from vacation next week.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitwar
Any other comment on this topic?
Can I go on and merge it to next?
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FA
On 22/11/13 19:03, Brad King wrote:
> On 11/22/2013 12:28 PM, David Cole wrote:
>> So I would add to the documentation saying that typically, only the
>> download and update steps ought to be considered as "independent" step
>> targets.
>
> Would it make sense to only allow it for specific steps
On 11/22/2013 12:28 PM, David Cole wrote:
> So I would add to the documentation saying that typically, only the
> download and update steps ought to be considered as "independent" step
> targets.
Would it make sense to only allow it for specific steps, or to disallow
it for specific steps for wh
Please review the topic ExternalProject-independent-step-targets.
Looks mostly reasonable. However, I'm concerned people will misuse it
to try to make all step targets "independent" when they shouldn't...
configure of project B usually depends on a successful install of
project A when B depe
Hello,
Please review the topic ExternalProject-independent-step-targets.
When adding step targets using ExternalProject_Add_StepTargets, the
STEP_TARGETS argument, or the EP_STEP_TARGETS property, ExternalProject
sets all the dependencies for the main project to that target. Due to
this, the upd
25 matches
Mail list logo
