[cmake-developers] [CMake 0015783]: ALIASED_TARGET property is always set

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15783 
== 
Reported By:Daniele E. Domenichelli
Assigned To:
== 
Project:CMake
Issue ID:   15783
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-10-12 16:32 CEST
Last Modified:  2015-10-12 16:32 CEST
== 
Summary:ALIASED_TARGET property is always set
Description: 
The ALIASED_TARGET property is always set even if no alias is associated to a
target. 

Steps to Reproduce: 
Using this CMakeLists.txt

---
cmake_minimum_required(VERSION 3.2)
project(test C)

file(WRITE ${CMAKE_BINARY_DIR}/test.c "int main(int argc, char *argv[]) { return
0; }\n")
add_executable(test_exe ${CMAKE_BINARY_DIR}/test.c)

get_property(_aliased_target_set TARGET test_exe PROPERTY ALIASED_TARGET SET)
if(_aliased_target_set)
  message(STATUS "ALIASED_TARGET is set for target test_exe")
  get_property(_aliased_target_value TARGET test_exe PROPERTY ALIASED_TARGET)
  message(STATUS "ALIASED_TARGET = \"${_aliased_target_value}\"")
else()
  message(STATUS "ALIASED_TARGET is NOT set for target test_exe")
endif()

include (CMakePrintHelpers)
cmake_print_properties(TARGETS test_exe PROPERTIES ALIASED_TARGET)


add_executable(Test::test_exe ALIAS test_exe)

get_property(_aliased_target_set TARGET Test::test_exe PROPERTY ALIASED_TARGET
SET)
if(_aliased_target_set)
  message(STATUS "ALIASED_TARGET is set for target Test::test_exe")
  get_property(_aliased_target_value TARGET Test::test_exe PROPERTY
ALIASED_TARGET)
  message(STATUS "ALIASED_TARGET = \"${_aliased_target_value}\"")
else()
  message(STATUS "ALIASED_TARGET is NOT set for target Test::test_exe")
endif()

include (CMakePrintHelpers)
cmake_print_properties(TARGETS Test::test_exe PROPERTIES ALIASED_TARGET CICCIO)
---




The actual output is

-- ALIASED_TARGET is set for target test_exe
-- ALIASED_TARGET = "_aliased_target_value-NOTFOUND"
--
 Properties for TARGET test_exe:
   test_exe.ALIASED_TARGET = "property-NOTFOUND"

-- ALIASED_TARGET is set for target Test::test_exe
-- ALIASED_TARGET = "test_exe"
--
 Properties for TARGET Test::test_exe:
   Test::test_exe.ALIASED_TARGET = "test_exe"



The expected output is

-- ALIASED_TARGET is NOT set for target test_exe
--
 Properties for TARGET test_exe:
   test_exe.ALIASED_TARGET = 

-- ALIASED_TARGET is set for target Test::test_exe
-- ALIASED_TARGET = "test_exe"
--
 Properties for TARGET Test::test_exe:
   Test::test_exe.ALIASED_TARGET = "test_exe"


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-10-12 16:32 Daniele E. DomenichelliNew Issue   

==

-- 

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

[cmake-developers] [CMake 0015784]: The WiX patch file parser ignores text nodes.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15784 
== 
Reported By:Ronny Krüger
Assigned To:
== 
Project:CMake
Issue ID:   15784
Category:   CPack
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-10-12 10:32 EDT
Last Modified:  2015-10-12 10:32 EDT
== 
Summary:The WiX patch file parser ignores text nodes.
Description: 
The following xml fragment is supposed to run the "test" action after the
installer has finished but only if the product is not installed.


  

  
  
NOT INSTALLED
  

  


Unfortunately this xml does not get completely through to WiX because the patch
parser ignores the text node below the "Custom" node which contains the
conditions on which the action is to be run.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-10-12 10:32 Ronny Krüger   New Issue
==

-- 

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] [Review Request] New module: IncludeUrl

[Brad King]

On 10/08/2015 02:28 PM, Daniele E. Domenichelli wrote:
> We've been successfully using this module for about 2 years now and we
> will continue to use it anyway, so I did not waste time...

I'm glad to hear that.

> I understand this is a quite controversial module, but I would like to
> stress that this is something that can already be done using CMake just
> by executing file(DOWNLOAD) and include(), this module just makes it
> easy to do it. Whether this is a security issue or not is up to how this
> module is used.

That makes sense, though I feel this may be a niche use case and would
prefer to hear more general interest.  If there is interest then for
upstream rather than a module perhaps this could be built in to the
include() command.

-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] [FindPostgreSQL] Search for version 9.5

[Brad King]

On 10/10/2015 03:37 PM, Tamar Kranenburg wrote:
> This small patch adds version 9.5 to the search suffixes.

Thanks, applied:

 FindPostgreSQL: Search for version 9.5
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5225e004

I've also queued this for merge to 'release' for 3.4.0-rc2.

-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] Issue on CMAKE_OSX_SYSROOT

[Brad King]

On 10/11/2015 06:17 AM, Gregor Jasny wrote:
>> if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
>>   set CMAKE_OSX_DEPLOYMENT_TARGET=
>> endif()

That logic looks right to me.

> Could you please give the following patch to Darwin-Initialize.cmake a try?
> 
> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=d61c6689c7380c810e060fed6bf3a0b9fbfd41d0

Francesco, does that resolve this for you?

> Brad: If we would set in line 33 the CMAKE_OSX_DEPLOYMENT_TARGET cache
> variable only if ENV{MACOSX_DEPLOYMENT_TARGET} actually exists we could
> get rid of the FORCE attribute later. Would that make sense?

The reason it is cached there is so that the initial selection is
cached persistently across runs.  One could refactor the logic to
use a normal variable at first and then cache the value later
once the final value is selected.

I think the FORCE approach is a good fixup to backport to 3.4.
The rest of the refactoring can be done in 'master' only, please.

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] Issue on CMAKE_OSX_SYSROOT

[Francesco Romano]

Hi
Sorry for the delay.

I tried it and it worked.
Thanks guys!

Francesco


> On 12 Oct 2015, at 17:00, Brad King  wrote:
> 
> On 10/11/2015 06:17 AM, Gregor Jasny wrote:
>>> if (SDK is newer than host) && (is not set CMAKE_OSX_DEPLOYMENT_TARGET)
>>>  set CMAKE_OSX_DEPLOYMENT_TARGET=
>>> endif()
> 
> That logic looks right to me.
> 
>> Could you please give the following patch to Darwin-Initialize.cmake a try?
>> 
>> https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=d61c6689c7380c810e060fed6bf3a0b9fbfd41d0
> 
> Francesco, does that resolve this for you?
> 
>> Brad: If we would set in line 33 the CMAKE_OSX_DEPLOYMENT_TARGET cache
>> variable only if ENV{MACOSX_DEPLOYMENT_TARGET} actually exists we could
>> get rid of the FORCE attribute later. Would that make sense?
> 
> The reason it is cached there is so that the initial selection is
> cached persistently across runs.  One could refactor the logic to
> use a normal variable at first and then cache the value later
> once the final value is selected.
> 
> I think the FORCE approach is a good fixup to backport to 3.4.
> The rest of the refactoring can be done in 'master' only, please.
> 
> 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] ITK NIfTI broken Oct 6

[Stephen Kelly]

Brad King wrote:

> Prior to this change the variable would have the right value in
> the subdirectory.  Now it is not set.  Please take a look.

This command has been documented as deprecated for a long time.

I notice this command is not covered by a policy.

 
https://cmake.org/cmake/help/v3.3/manual/cmake-commands.7.html#deprecated-commands

Pushed:

 Subdirs: Initialize from parent before configuring.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2

Thanks,

Steve.

-- 

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] ITK NIfTI broken Oct 6

[Brad King]

On 10/09/2015 10:06 AM, Kevin H. Hobbs wrote:
> The ITK dashboard builds on bubbles, murron, and k450e all started
> failing at the configure step on October 6.
> 
> CMake Error at
> Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
>   install TARGETS given no LIBRARY DESTINATION for shared library target
>   "znz".

Kevin, thanks for reporting this promptly.

Steve, this bisects to:

 cmMakefile: Move invokation to initialize snapshot.
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f716460e

Here is a small test case:

 $ cat CMakeLists.txt
 cmake_minimum_required(VERSION 3.3)
 project(Subdir NONE)
 subdirs(dir)
 set(variable value)

 $ cat dir/CMakeLists.txt
 message("variable='${variable}'")

Prior to this change the variable would have the right value in
the subdirectory.  Now it is not set.  Please take a look.

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] Moving from Module to Target-based linking

[Ryan Pavlik]

Apparently the approach in FindGLUT does not work with the latest Mac build
tools, the file referenced is no longer a symlinks to the library but a
text metadata file, as I'm told by a Mac contributor to an open source
project I maintain. I was under the impression that it was a known issue,
perhaps it was not filed yet as a bug.  (cf.
https://github.com/OSVR/OSVR-Core/pull/232#issuecomment-147109322 )


Ryan

On Thu, Oct 8, 2015, 10:23 AM Brad King  wrote:

> On 10/08/2015 08:58 AM, Ryan Pavlik wrote:
> > Happy to learn the correct way to make an imported target for a found
> > framework if someone cares to enlighten :)
>
> There is an example in FindGLUT.  Ideally find_library should be taught
> to find the "foo.framework/foo" file instead of the "foo.framework"
> directory but that will require a policy and some other changes to
> accomplish.
>
> > On Wed, Oct 7, 2015, 3:04 AM Daniel Wirtz wrote:
> >> is there any development going on towards providing FindXXX.cmake
> >> wrapper modules that "convert" MODULE-mode results into CONFIG style
> >> imported targets to consume?
>
> We'd like to head in that direction but there is no plan for a dedicated
> sweep through all modules by upstream devs.  We're depending on users
> to contribute conversions for the modules they need.
>
> -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
>
-- 

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] ITK NIfTI broken Oct 6

[Kevin H. Hobbs]

On 10/12/2015 01:09 PM, Brad King wrote:
> On 10/09/2015 10:06 AM, Kevin H. Hobbs wrote:
>> The ITK dashboard builds on bubbles, murron, and k450e all started
>> failing at the configure step on October 6.
>>
>> CMake Error at
>> Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
>>   install TARGETS given no LIBRARY DESTINATION for shared library target
>>   "znz".
> 
> Kevin, thanks for reporting this promptly.
> 

Brad,

You're welcome.

I'm sorry for my impatient cross posting to the ITK developer's list.





signature.asc
Description: OpenPGP digital signature
-- 

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] ITK NIfTI broken Oct 6

[Brad King]

On 10/12/2015 01:48 PM, Stephen Kelly wrote:
> This command has been documented as deprecated for a long time.
>
> I notice this command is not covered by a policy.

Back when 3.0 deprecated a swath of old commands with policies
we decided that subdirs() was too widely used to warn about
(along with so many of the other commands that got policies).
With that batch over we could reconsider.  OTOH we still
generate subdirs() commands in CTestTestfile.cmake files for
"ctest" to use, though CTest re-implements the command itself
IIRC.

>  Subdirs: Initialize from parent before configuring.
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2

Great, thanks.

Doesn't that mean that subdirs()-specified directories now
InitializeFromParent twice?

-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] ITK NIfTI broken Oct 6

[Stephen Kelly]

Brad King wrote:

> On 10/12/2015 01:48 PM, Stephen Kelly wrote:
>> This command has been documented as deprecated for a long time.
>>
>> I notice this command is not covered by a policy.
> 
> Back when 3.0 deprecated a swath of old commands with policies
> we decided that subdirs() was too widely used to warn about
> (along with so many of the other commands that got policies).
> With that batch over we could reconsider.  OTOH we still
> generate subdirs() commands in CTestTestfile.cmake files for
> "ctest" to use, though CTest re-implements the command itself
> IIRC.

I've seen this, but haven't looked into it.

>>  Subdirs: Initialize from parent before configuring.
>>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2
> 
> Great, thanks.
> 
> Doesn't that mean that subdirs()-specified directories now
> InitializeFromParent twice?

Yes, but that doesn't matter because the second one will overwrite the 
effect of the first one. It's just part of the cost if you use deprecated 
commands.

Thanks,

Steve.


-- 

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] Issue on CMAKE_OSX_SYSROOT

[Brad King]

On 10/12/2015 11:15 AM, Francesco Romano wrote:
> I tried it and it worked.

Great, thanks for testing.

I rebased on 'release' and merged to 'next':

 Xcode: Adjust deployment target SDK version to host version
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24aafbde

I've queued this for merge to 'release' for inclusion in
3.4.0-rc2 since it is an environmental regression.

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] re-install timestamp comparison (was: OS X: Filesystem timestamp checks use only 1s resolution)

[Brad King]

On 10/09/2015 07:02 PM, Ruslan Baratov wrote:
> On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote:
>> cmFileTimeComparisonInternal::TimesDiffer use only limited number of
>> digits of timestamp and used in install step.
>>
> And the main difference is that it affects Linux platform too

IIRC that is done for the case that one installs from one
filesystem to another and they each have different timestamp
resolution.  If we don't round the times then they may always
differ and inefficiently re-install everything every time.

Ideally we would detect the resolution available on each
filesystem and truncate only to the lower resolution of the
two.  Perhaps one could at least detect when the source and
destination are on the same filesystem and do no truncation.

Another approach would be to try writing the destination
file time to see if it changes.  If so then re-install
and set the time again.  This would happen only when really
on filesystems with different time resolutions because
otherwise the file times would match.  This way a failure
to re-install would occur only on a truly 1s filesystem.

-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] Generating buildsystem metadata from CMake

[Alexander Neundorf]

Hi,

On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote:
> Aleix Pol wrote:
> > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
> > 
> >  wrote:
> >> Stephen Kelly wrote:
> >>> The aim is to generate a structured file containing metadata 
relating
> >>> the buildsystem.
> >> 
> >> I've been quiet on this thread for a while, so I think it is time for an
> >> update.
> >> 
> >> I became more ambitious in mid March and started prototyping a
> >> more-complete design for CMake IDE integration.
> > 
> > Hi Stephen,
> > Is there any news on the subject?
> 
> I have been working on cleaning up cmake
> 
>  $ git log --oneline --author=steveire --since="April 1" | wc -l
>  472
> 
> I've made lots of progress toward separating the configure and 
generation
> steps (required prerequisite for server features), but no working 
prototype
> ready to show yet I'm afraid.

Maybe this is of interest: the Eclipse CDT developers are currently 
working on improved support for cmake:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

But if I understand them correctly, this is not about improving support for 
projects which use cmake without eclipse, but to use cmake as the tool 
to generate the makefiles in Eclipse projects. But maybe I got that 
wrong.

Alex

-- 

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

[cmake-developers] GHS MULTI generator link with RUNTIME_OUTPUT_DIRECTORY patch

[Geoffrey Viola]

Attached is a patch to allow the GHS MULTI generator to link a library when 
it's directory has changed via the RUNTIME_OUTPUT_DIRECTORY.


Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com


This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.


0001-GHS-MULTI-generator-link-with-RUNTIME_OUTPUT_DIRECTO.PATCH
Description: 0001-GHS-MULTI-generator-link-with-RUNTIME_OUTPUT_DIRECTO.PATCH
-- 

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