Re: [CMake] Symlinks not created on OS X

[Jerry]

On Nov 1, 2011, at 6:56 AM, Sean McBride wrote:

> On Mon, 31 Oct 2011 17:27:38 -0700, Jerry said:
> 
>> The OS X .dmg installer, cmake-2.8.6-Darwin64-universal.dmg, at http://
>> www.cmake.org/cmake/resources/software.html, failed to install symlinks
>> in /usr/bin as promised. I received six messages, I think from the Cmake
>> app, of this nature:
>> 
>> Failed create symlink installation may be incomplete: x
>> 
>> where x was ccmake, cmake, cmake-gui, cmakexbuild, cpack, and ctest. I
>> made the symlinks manually and things seem to work OK.
> 
> Perhaps you're seeing this:
> 

Yes, that fits my situation as well.
> 
> see also:
> 

I don't believe my situation is related to this naming question. FWIW, my vote 
goes to the Mac tradition--no version names on .apps.

Thanks for your help, and for Cmake!
> 
> --
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com
> Mac Software Developer  Montréal, Québec, Canada
> 
> 

--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to force value to cache variable without retyping doc string?

[Robert Dailey]

Thanks, I didn't even think of doing it like that :)

This works great. Thanks!

-
Robert Dailey


On Tue, Nov 1, 2011 at 3:46 PM, Fraser Hutchison <
fraser.hutchi...@googlemail.com> wrote:

>  Hi Robert,
>
> I think you need something like:
>
>
> if( NOT COPY_DONE )
> ... do work 
> set( COPY_DONE true CACHE BOOL "This is my documentation" FORCE )
> endif()
>
> Cheers,
>
> Fraser.
>
>
>
> On 01/11/2011 18:37, Robert Dailey wrote:
>
> There is a one-time operation I need CMake to perform the very first time
> a user generates. This operation involves copying several files from a
> remote server (third party libraries) and placing them in the binary dir.
>
>  Right now I'm attempting to do this via a cache variable:
>
>  set( COPY_DONE false CACHE BOOL "This is my documentation" )
> if( NOT COPY_DONE )
> ... do work 
> set( COPY_DONE true )
> endif()
>
>  I do not make this an INTERNAL cache variable because at any time the
> user should be able to set COPY_DONE to false manually and it should recopy
> everything, and then set it back to 'true'.
>
>  The code above does not work because I'm not using set( COPY_DONE true
>  FORCE ). But I have to resupply the docstring if I do it this
> way.
>
>  Am I going about this the wrong way? Can anyone recommend a different
> approach? If not, how can I do this without having to duplicate the doc
> string?
>
>  -
> Robert Dailey
>
>
> --
>
> 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_FAQ
>
> Follow this link to 
> subscribe/unsubscribe:http://www.cmake.org/mailman/listinfo/cmake
>
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] debug/optimized include directories

[Robert Dailey]

Well if you need any help coding the feature let me know. I'm already
liking the idea of adding features I want myself into CMake :)

Thanks!

-
Robert Dailey


On Tue, Nov 1, 2011 at 3:47 PM, David Cole  wrote:

> On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey  wrote:
> > On Tue, Nov 1, 2011 at 3:32 PM, David Cole 
> wrote:
> >>
> >> Not yet
> >
> > Meaning there are plans in the works to add such functionality in the
> near
> > future?
> > For now I guess I could actually hard code VS environment variables in my
> > include directory strings, such as $(Configuration).
>
> There is a feature planned to add per-target include directories (as a
> target property). As part of that work, we will probably naturally
> also add per-configuration values of that new target property. It is
> not yet added as a feature request in the bug tracker, but there are
> related ones that I may "borrow" for the purpose. Stay tuned for more
> info, but it is not coming in the next week or two. Hopefully, in time
> for 2.8.7, but it depends on timing at this point so no promises.
>
> For now, your $(Configuration) idea is probably your best bet. (And
> would continue to work even after we implement this feature...)
>
>
> HTH,
> David
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] debug/optimized include directories

[David Cole]

On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey  wrote:
> On Tue, Nov 1, 2011 at 3:32 PM, David Cole  wrote:
>>
>> Not yet
>
> Meaning there are plans in the works to add such functionality in the near
> future?
> For now I guess I could actually hard code VS environment variables in my
> include directory strings, such as $(Configuration).

There is a feature planned to add per-target include directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property. It is
not yet added as a feature request in the bug tracker, but there are
related ones that I may "borrow" for the purpose. Stay tuned for more
info, but it is not coming in the next week or two. Hopefully, in time
for 2.8.7, but it depends on timing at this point so no promises.

For now, your $(Configuration) idea is probably your best bet. (And
would continue to work even after we implement this feature...)


HTH,
David
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] debug/optimized include directories

[Robert Dailey]

On Tue, Nov 1, 2011 at 3:32 PM, David Cole  wrote:

> Not yet


Meaning there are plans in the works to add such functionality in the near
future?

For now I guess I could actually hard code VS environment variables in my
include directory strings, such as $(Configuration).
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] debug/optimized include directories

[David Cole]

Not yet

On Tue, Nov 1, 2011 at 4:30 PM, Robert Dailey  wrote:
> When generating for Visual Studio, is there a way to make projects in debug
> configuration have a different set of include directories from the release
> configuration?
>
> -
> Robert Dailey
>
> --
>
> 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_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] debug/optimized include directories

[Robert Dailey]

When generating for Visual Studio, is there a way to make projects in debug
configuration have a different set of include directories from the release
configuration?

-
Robert Dailey
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPACK not generating binary install

[Eric Noulard]

2011/11/1 David Cole :
> INSTALL rule DESTINATION arguments are intended to be non-full path
> directory names, that get placed underneath CMAKE_INSTALL_PREFIX.
>
> When CPack runs, it tries to build the install target after setting a
> value into CMAKE_INSTALL_PREFIX.
>
> Since your install rules ignore this, by giving full path DESTINATION
> values, the install tree that CPack builds does not get all the right
> stuff copied into it.

I think we should generate a warning for ABSOLUTE installed files
and CPack, many people fall into this caveat.
What do you think?


> Try using just "bin" and "lib" as the DESTINATION values, and then
> adjusting CMAKE_INSTALL_PREFIX to put the root of the install tree
> where you want it.

Just a precision:

CPack is not using the project's CMAKE_INSTALL_PREFIX
(unless you set CPACK_SET_DESTDIR to ON)
but CPACK_PACKAGING_INSTALL_PREFIX

in summary:

  CMAKE_INSTALL_PREFIX is used for "make install"
  CPACK_PACKAGING_INSTALL_PREFIX is used for "cpack -G "

Moreover, each CPack generator has a default value for
"CPACK_PACKAGING_INSTALL_PREFIX"
which is used whenever the user did not specified it;

One more thing,
you'd better move your "include(CPack)" near the end of your main CMakeLists.txt
and in any case after the "add_subdirectory".

Putting it before some target  definition will lead to unexpected behavior.

include(CPack) is more or less equivalent to a function call for which
parameters were defined "globally" before the call.

For the very same reason any CPACK_xxx var definition should be done
**BEFORE** including CPack.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPACK not generating binary install

[David Cole]

INSTALL rule DESTINATION arguments are intended to be non-full path
directory names, that get placed underneath CMAKE_INSTALL_PREFIX.

When CPack runs, it tries to build the install target after setting a
value into CMAKE_INSTALL_PREFIX.

Since your install rules ignore this, by giving full path DESTINATION
values, the install tree that CPack builds does not get all the right
stuff copied into it.

Try using just "bin" and "lib" as the DESTINATION values, and then
adjusting CMAKE_INSTALL_PREFIX to put the root of the install tree
where you want it.

Then it should "just work" with CPack.


HTH,
David


On Tue, Nov 1, 2011 at 1:20 PM, Darrell Langford
 wrote:
> I'm trying to use CPACK to generate a binary installer, I can get a source
> installer to sort of work, but I don't need the source at all.  We do out of
> source builds, but I have CMAKE place my libs and bins back into the source
> tree under a parent/project/lib and parent/project/bin directory for each
> project
> Make install installs everything to
> parent/application/bin parent/application/lib parent/application/data
> I have a large directory structure with multiple libraries and a single
> executable setup like this
> parent/project/
> My Parent CMakeLists.txt file looks like this:
> project(parent)
> set(COMMON_INSTALL_DIR ${PROJECT_SOURCE_DIR}/../MyProgram)
> set(COMMON_LIB_INSTALLS ${COMMON_INSTALL_DIR}/lib)
> set(COMMON_BIN_INSTALLS ${COMMON_INSTALL_DIR}/bin)
>
> INCLUDE(CPack)
> add_subdirectory(project1)
> add_subdirectory(project2)
> add_subdirectory(projectApp)
>
> If I just leave it at the parent tree, then make package creates empty .tgz
> trees.
> Under Project1 it looks like this
> Project1/CMakeLists.txt
> project(project1)
> SET(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
> SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
> add_subdirectory(src)
> Project1/src/CMakeLists.txt
> usual stuff to get a build and
> add_library(project1 SHARED ${PROJECT1_SOURCES})
> install(TARGETS project1 LIBRARY DESTINATION ${COMMON_LIB_INSTALLS})
>
> If I populate the INCLUDE(CPack) across the three cmakes, then it builds a
> source fine, but no binary.
> Everything else works perfect for me, make, make install, we even have
> testing setup under a parent/project1/test directory, it's just CPACK that
> is causing me some headaches.
> So what I want from this is when I run make install it goes to the directory
> parent/MyProgram with /lib /data /bin folders under it
> and then I really just want CPack to package that Folder up, I can force
> this using SET(CPACK_INSTALLED_DIRECTORIES
> "${COMMON_INSTALL_DIR};MyProgram") but I was trying to figure out why the
> other doesn't work.
> Thanks for your help,
> D
>
> --
>
> 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_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to force value to cache variable without retyping doc string?

[Robert Dailey]

There is a one-time operation I need CMake to perform the very first time a
user generates. This operation involves copying several files from a remote
server (third party libraries) and placing them in the binary dir.

Right now I'm attempting to do this via a cache variable:

set( COPY_DONE false CACHE BOOL "This is my documentation" )
if( NOT COPY_DONE )
... do work 
set( COPY_DONE true )
endif()

I do not make this an INTERNAL cache variable because at any time the user
should be able to set COPY_DONE to false manually and it should recopy
everything, and then set it back to 'true'.

The code above does not work because I'm not using set( COPY_DONE true
 FORCE ). But I have to resupply the docstring if I do it this
way.

Am I going about this the wrong way? Can anyone recommend a different
approach? If not, how can I do this without having to duplicate the doc
string?

-
Robert Dailey
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Joining & Normalizing paths

[Alexander Neundorf]

On Tuesday 01 November 2011, Robert Dailey wrote:
> I don't see a way to join or normalize paths in CMake. For example, there
> is a "base path" that the user can specify in a cache variable, like so:
> 
> BASE_PATH = "T:/stuff/"
> 
> Later in my CMake script, I join a subpath to it like so:
> 
> "${BASE_PATH}/morestuff"
> 
> The problem is, this becomes:
> 
> "T:/stuff//morestuff"
> 
> Notice the double slash. Also if the user specifies backslashes in the
> variable, you get this:
> 
> "T:\stuff\/morestuff"
> 
> Normalization would be ideal here, or a way to properly join the paths like
> so:
> 
> path( JOIN "${BASE_PATH}" "morestuff" )
> 
> Which would yield the cmake path:
> 
> "T:/stuff/morestuff"
> 
> Is any of this possible? How do I work around this?

Does file(TO_CMAKE_PATH ... ) what you want ?

Alex
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Joining & Normalizing paths

[Robert Dailey]

I don't see a way to join or normalize paths in CMake. For example, there
is a "base path" that the user can specify in a cache variable, like so:

BASE_PATH = "T:/stuff/"

Later in my CMake script, I join a subpath to it like so:

"${BASE_PATH}/morestuff"

The problem is, this becomes:

"T:/stuff//morestuff"

Notice the double slash. Also if the user specifies backslashes in the
variable, you get this:

"T:\stuff\/morestuff"

Normalization would be ideal here, or a way to properly join the paths like
so:

path( JOIN "${BASE_PATH}" "morestuff" )

Which would yield the cmake path:

"T:/stuff/morestuff"

Is any of this possible? How do I work around this?

-
Robert Dailey
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPACK not generating binary install

[Darrell Langford]

I'm trying to use CPACK to generate a binary installer, I can get a source 
installer to sort of work, but I don't need the source at all.  We do out of 
source builds, but I have CMAKE place my libs and bins back into the source 
tree under a parent/project/lib and parent/project/bin directory for each 
project

Make install installs everything to 
parent/application/bin parent/application/lib parent/application/data 

I have a large directory structure with multiple libraries and a single 
executable setup like this
parent/project/

My Parent CMakeLists.txt file looks like this:

project(parent)

set(COMMON_INSTALL_DIR ${PROJECT_SOURCE_DIR}/../MyProgram)
set(COMMON_LIB_INSTALLS ${COMMON_INSTALL_DIR}/lib)

set(COMMON_BIN_INSTALLS ${COMMON_INSTALL_DIR}/bin)


INCLUDE(CPack)

add_subdirectory(project1)
add_subdirectory(project2)

add_subdirectory(projectApp)


If I just leave it at the parent tree, then make package creates empty .tgz 
trees.

Under Project1 it looks like this
Project1/CMakeLists.txt

project(project1)
SET(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)

add_subdirectory(src)

Project1/src/CMakeLists.txt
usual stuff to get a build and

add_library(project1 SHARED ${PROJECT1_SOURCES})
install(TARGETS project1 LIBRARY DESTINATION ${COMMON_LIB_INSTALLS})


If I populate the INCLUDE(CPack) across the three cmakes, then it builds a 
source fine, but no binary.

Everything else works perfect for me, make, make install, we even have testing 
setup under a parent/project1/test directory, it's just CPACK that is causing 
me some headaches.

So what I want from this is when I run make install it goes to the directory

parent/MyProgram with /lib /data /bin folders under it

and then I really just want CPack to package that Folder up, I can force this 
using SET(CPACK_INSTALLED_DIRECTORIES "${COMMON_INSTALL_DIR};MyProgram") but I 
was trying to figure out why the other doesn't work.

Thanks for your help,

D
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] SCC bindings missing AUXPATH support?

[Steven Velez]

Just to be clear, I am not advocating having to deal with the perforce
SCC integration dialog for every project in the solution.  In our set
up, we need to deal with it once for the solution... without having
access to AuxPath.  However, I do imagine, that it probably has
something to do with where the local path ends up pointing to and
whether your solution pulls projects from different P4 work-spaces,
though I have never done that myself personally.

I suggested making AuxPath optional because the binding will work
without that property, and it will work efficiently if carefully
crafted.  I can not say that a binding will succeed if any of the
other properties are omitted, though perhaps they might with some SCC
providers... I didn't write the original binding logic, I don't use
other providers, and I certainly have never seen any documentation on
the Visual Studio SCC interface... I've heard you need to sign an NDA
with Microsoft for that or something.

As far as there being logic to using a relative path as opposed to an
absolute one, no... I can't say that I know what it is if there is
any.  Again, I don't fully understand how SCC integration works.  I
can only say that I have tried relative paths, and they work better
for me than the report you provided originally.  Also, if I set up the
bindings after solution generation from within visual studio 2010,
that is what the IDE and/or perforce puts there.

Steven

On Tue, Nov 1, 2011 at 7:40 AM, Robert Dailey  wrote:
> On Mon, Oct 31, 2011 at 11:59 PM, Steven Velez  wrote:
>>
>> Hi Robert,
>>
>> I reviewed the patch, and I am not sure vsAuxPath should be a
>> requirement.  As I stated earlier, we've gotten the binding to work
>> acceptably without it and I assume others have as well.  Further, some
>> users may prefer to enter their connection information in to the
>> perforce dialog on first invocation instead of having to configure the
>> cmake cache to setup their bindings.
>
> I never said it wouldn't work without AuxPath, I am just stating that it
> works better with it. AuxPath is where the connection string is placed.
> Each person that uses CMake is different and I see no reason why AuxPath
> should not be an available option to the user, especially since I've already
> done the work of adding it in.
> If users want to continuously press "OK" on the perforce connection dialog
> for every project opened in the solution, that's fine by me but I certainly
> don't want to deal with that annoying behavior.
>
>>
>> To be clear, I have no objections to adding AuxPath support (not that
>> my objections count for anything around here).  Its that just as it
>> stands now, if you don't supply it, you won't get any bindings.
>
> I can easily make it optional. I was just following the design already in
> place, which forces all parameters to be required.
>
>>
>> Also, you may have better results getting your patch integrated by
>> opening a defect in cmake's bug tracker and attaching the patch to
>> that.  The preferred patch generation method is also described here:
>> http://www.mail-archive.com/cmake@cmake.org/msg36619.html
>
> Thanks for the info!!
>
>>
>> By the way, as I stated in an earlier mail, if you wish to pursue this
>> further, if you change "C:/Code/work/sandbox" to "..\..\.." where that
>> path points to "C:\Code\work\sandbox" relative to the target being
>> bound, you should have better results.
>
> I read your last email but I fail to see the logic behind why a relative
> path works better than an absolute one. Based on my tests, using an absolute
> path has not resulted in any prompts to save the solution/projects.
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSVC variable doesn't work without project() call first

[Robert Dailey]

On Tue, Nov 1, 2011 at 10:43 AM, David Cole  wrote:

> On Tue, Nov 1, 2011 at 11:22 AM, Alexander Neundorf
>  wrote:
> > On Tuesday 01 November 2011, Robert Dailey wrote:
> >> For some reason the built in variable like MSVC_VERSION and MSVC do not
> >> have any value unless the project() command is called first. Can someone
> >> explain why?
> >
> > Without checking...
> > IIRC, the project() call enables by default the C and the CXX languages
> (if
> > that hasn't been done before explicitely).
> > During enabling the languages the compilers are detected, and with them
> those
> > variables are set.
> > So, before that no languages are known to cmake, so these variables are
> not
> > set.
> >
> > Alex
> > --
> >
> > 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_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
> >
>
> Alex is right.
>
> If you need the value of MSVC *before* calling the project command for
> some reason, then you can call enable_language(C) (or CXX) instead...


I don't need MSVC checking before project() in my case, they just seemed
unrelated so I wanted to check for educational purposes :)

Thanks guys.
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSVC variable doesn't work without project() call first

[David Cole]

On Tue, Nov 1, 2011 at 11:22 AM, Alexander Neundorf
 wrote:
> On Tuesday 01 November 2011, Robert Dailey wrote:
>> For some reason the built in variable like MSVC_VERSION and MSVC do not
>> have any value unless the project() command is called first. Can someone
>> explain why?
>
> Without checking...
> IIRC, the project() call enables by default the C and the CXX languages (if
> that hasn't been done before explicitely).
> During enabling the languages the compilers are detected, and with them those
> variables are set.
> So, before that no languages are known to cmake, so these variables are not
> set.
>
> Alex
> --
>
> 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_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>

Alex is right.

If you need the value of MSVC *before* calling the project command for
some reason, then you can call enable_language(C) (or CXX) instead...
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSVC variable doesn't work without project() call first

[Alexander Neundorf]

On Tuesday 01 November 2011, Robert Dailey wrote:
> For some reason the built in variable like MSVC_VERSION and MSVC do not
> have any value unless the project() command is called first. Can someone
> explain why?

Without checking...
IIRC, the project() call enables by default the C and the CXX languages (if 
that hasn't been done before explicitely).
During enabling the languages the compilers are detected, and with them those 
variables are set.
So, before that no languages are known to cmake, so these variables are not 
set.

Alex
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] MSVC variable doesn't work without project() call first

[Robert Dailey]

For some reason the built in variable like MSVC_VERSION and MSVC do not
have any value unless the project() command is called first. Can someone
explain why?

-
Robert Dailey
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Weird linking error while cross compiling

[Michael Hertling]

On 10/28/2011 06:20 PM, Jose wrote:
> I give up. [...]

Never say die. ;)

> [...] I solved the problem with the solution Michael gave me. Actually
> this linking flag : -Bstatic
> was the causant of the troubles.

Out of curiosity: We've seen the failing link line; how does the
successful one look alike? Do you still use the -Bstatic flag?

> Nevertheless now I get undefined references to functions defined in the
> library "portablexdr" .
> 
> I have been trying to fix it for two days without success. The library is
> being linked and I have checked the content of the library with
> mingw32-nm and it has all the functions defined.
> 
> I have to say that I modified and rebuilt the library to include some
> functions that were not present ( portableXDR does not follow the Sun XDR
> standard). So I guess this is what it is
> causing me the troubles but It should not since I rebuilt it without
> problems and when I check the content of the library with nm the functions
> are there.
> 
> Any help??

Could you provide some more information, i.e. excerpts from the "make
VERBOSE=1" output and the concerned CMakeLists.txt files, especially
the latters' TARGET_LINK_LIBRARIES() commands? Ideally, you should
post a small self-contained example which demonstrates the issue.

Regards,

Michael

> 2011/10/26 Michael Hertling 
> 
>> On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
>>> On 26.10.11 03:54:02, Jose wrote:
 Sorry for not being very specific.

 This is the command that Cmake is running while linking :

 /usr/bin/i686-pc-mingw32-g++  -O3 -O3-Wl,-Bstatic -static-libgcc
 -Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a
>> -Wl,--no-whole-archive
 -o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
 -Wl,--major-image-version,0,--minor-image-version,0
 -L/home/fedora/percolator/percolator/src/converters/../../src
 libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
 MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr

>> /home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
 -lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool
>> -lshell32
 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
 /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
 cannot find -lxerces-c
 /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
 cannot find -lportablexdr
 /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
 cannot find -lz
 /usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
 cannot find -lsqlite3

 That is weird cos I "load" all the libraries in the same way and they
>> all
 the variables content the right paths to the libraries : (for example)

 Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a ,
>> XDR :
 /usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a

 This is how I link :

 #COMPILING SQT2PIN
 include_directories(. MSToolkit/RAMP MSToolkit )
 add_executable(sqt2pin Sqt2Pin.cpp )
 IF(STATIC AND MINGW)
   set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
   set_target_properties(sqt2pin PROPERTIES LINK_FLAGS "-Wl,-Bstatic
 -static-libgcc")
 ENDIF()
 message(STATUS "Xercesc : ${XERCESC_LIBRARIES} , XDR :
 ${PORTABLEXDR_LIBRARIES}")
 target_link_libraries(sqt2pin converters perclibrary_part  MSToolkit
>> RAMP
 ${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES}
>> )

 I might  be missing something very stupid because I use the same
>> prodecure
 to search for the librarysthe FindXXX.cmake macros that are tested
>> and
 working with other programs.

 Could it be the include_directories("library include dir") which is
>> messing
 this up? it looks like the linker disregard the path of the library that
>> Im
 pasinng and looks for -lxerces-c instead. Is that xerces-c defined
>> somehow
 before?
>>>
>>> This happens if the library is considered to be in a 'system path' since
>>> in that case specifying the path is not necessary for the linker to find
>>> it. However in your specific case it seems like cmake does this even for
>>> static libraries, which is of course wrong. I'd suggest to file a
>>> bugreport for this with a small self-contained example.
>>>
>>> Andreas
>>
>> The -l switch of ld is not related to the library's type, i.e.
>> shared or static; see ld's manpage and the following example:
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(STATIC C)
>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "int f(void){return 0;}\n")
>> EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
>> EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return f();}\n")
>> ADD_EXECUTABLE(main main.c)
>> TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /

Re: [CMake] Symlinks not created on OS X

[Sean McBride]

On Mon, 31 Oct 2011 17:27:38 -0700, Jerry said:

>The OS X .dmg installer, cmake-2.8.6-Darwin64-universal.dmg, at http://
>www.cmake.org/cmake/resources/software.html, failed to install symlinks
>in /usr/bin as promised. I received six messages, I think from the Cmake
>app, of this nature:
>
>Failed create symlink installation may be incomplete: x
>
>where x was ccmake, cmake, cmake-gui, cmakexbuild, cpack, and ctest. I
>made the symlinks manually and things seem to work OK.

Perhaps you're seeing this:


see also:


-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Robert Dailey]

I realize this is a feature but since I've provided the patch files that
implement this (attached to the bug below) I was hoping you wouldn't mind.
It's a small feature addition for source control bindings. Read more here:
http://public.kitware.com/Bug/view.php?id=12549

-
Robert Dailey


On Fri, Oct 28, 2011 at 10:26 AM, Robert Dailey  wrote:

> I just created a bug here:
> http://public.kitware.com/Bug/view.php?id=12545
>
> The issue involves duplicate entries in the Add Remove Programs dialog in
> Windows 7 when installing upgrades for CMake using the installer. I'd like
> to see this cleaned up by the next release, as subsequent upgrades will
> surely only add more duplicated entries.
>
> -
> Robert Dailey
>
>
>
> On Fri, Oct 21, 2011 at 11:19 AM, David Cole wrote:
>
>> Hi all,
>>
>> *NO* replies requested. Different technique this time. Please edit the
>> bug tracker directly. (Unless you have problems with the bug tracker:
>> if so, please feel free to reply here with your suggestions.)
>>
>> We are planning for CMake 2.8.7, aiming for a December release. We're
>> targeting Dec. 28, 2011 for releasing it, and in order to make that
>> happen we'll have to do an "rc1" by Dec. 7th or so... about 7 weeks
>> from now.
>>
>> If you have a particular issue that you think should be fixed for
>> inclusion in 2.8.7, please put it on the roadmap yourself by the end
>> of next week, Fri. Oct. 28th. To do so, edit the bug at
>> http://public.kitware.com/Bug and set the "Target Version" field to
>> "CMake 2.8.7" - that will make it appear on the roadmap page (
>> http://www.cmake.org/Bug/roadmap_page.php?version_id=89 ). Also: add a
>> note saying why it's important to you, or even add a patch that fixes
>> and documents and tests it if you're able to.
>>
>> Ideally, each issue will be discussed as needed on the mailing list to
>> come to any consensus about what should be done to fix it, and then
>> the entry in the bug tracker may be used to keep it on the radar
>> screen, and to track activity related to it.
>>
>> Patches are *always* welcome. Patches that include testing of any new
>> features, or tests that prove a bug is really fixed on the dashboards
>> are better: a patch with testing is strongly preferred over a patch
>> with no testing. Also, if you are *adding* code, then you also
>> probably need to add *tests* of that code, so that the coverage
>> percentage stays as is or rises.
>>
>> Please discuss issues here on the mailing list as needed, and add
>> notes to existing issues in the bug tracker that you are interested in
>> seeing fixed for 2.8.7 -- we will be looking at activity both on the
>> mailing list and in the bug tracker to help prioritize the bug fixes
>> for the next couple months.
>>
>>
>> Thanks,
>> David Cole
>> Kitware, Inc.
>>
>>
>> P.S. - as a nice summary of what we accomplished in the CMake 2.8.6
>> release, including contributions from 27 individuals around the world,
>> see here: http://public.kitware.com/Bug/changelog_page.php?version_id=87
>> -- it currently lists 43 issues that we resolved: nice job, everybody!
>>
>> (Many of those were specifically addressed because somebody brought it
>> up in response to my similar email from just after 2.8.5... Don't be
>> shy!)
>> --
>>
>> 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_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] SCC bindings missing AUXPATH support?

[Robert Dailey]

On Mon, Oct 31, 2011 at 11:59 PM, Steven Velez  wrote:

> Hi Robert,
>
> I reviewed the patch, and I am not sure vsAuxPath should be a
> requirement.  As I stated earlier, we've gotten the binding to work
> acceptably without it and I assume others have as well.  Further, some
> users may prefer to enter their connection information in to the
> perforce dialog on first invocation instead of having to configure the
> cmake cache to setup their bindings.
>

I never said it wouldn't work without AuxPath, I am just stating that it
works better with it. AuxPath is where the connection string is placed.

Each person that uses CMake is different and I see no reason why AuxPath
should not be an available option to the user, especially since I've
already done the work of adding it in.

If users want to continuously press "OK" on the perforce connection dialog
for every project opened in the solution, that's fine by me but I certainly
don't want to deal with that annoying behavior.


> To be clear, I have no objections to adding AuxPath support (not that
> my objections count for anything around here).  Its that just as it
> stands now, if you don't supply it, you won't get any bindings.
>

I can easily make it optional. I was just following the design already in
place, which forces all parameters to be required.


> Also, you may have better results getting your patch integrated by
> opening a defect in cmake's bug tracker and attaching the patch to
> that.  The preferred patch generation method is also described here:
> http://www.mail-archive.com/cmake@cmake.org/msg36619.html


Thanks for the info!!


> By the way, as I stated in an earlier mail, if you wish to pursue this
> further, if you change "C:/Code/work/sandbox" to "..\..\.." where that
> path points to "C:\Code\work\sandbox" relative to the target being
> bound, you should have better results.
>

I read your last email but I fail to see the logic behind why a relative
path works better than an absolute one. Based on my tests, using an
absolute path has not resulted in any prompts to save the solution/projects.
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] To warn or to error out ? - wording and compatiblity

[Eric Noulard]

2011/11/1 Alexander Neundorf :
> On Tuesday 01 November 2011, Eric Noulard wrote:
[...]
>> So before making the build dir as a source subdir case FATAL, are you sure
>> we really don't want to authorize the generatiion of .project
>> .cproject in the source dir
>> in this very particular but nervertheless very useful case?
>
> I'm quite sure that there are strong objections to this among the other cmake
> developers.

Eh I'm strong too ;-)

No I'm 100% for clean rules about not polluting the build tree with
some generated files.
The thing is, last time (back in 2007) I tried to go as far as I can with this
Eclipse limitation. Digging & asking on CMake ML and CdT ML.

**I** think eclipse people just don't care about this particular use case
so the chance that Eclipse takes into account this case is fairly ... tiny.
I could have proposed patch for Eclipse Team I just don't have enough
knowledge to do it  and not enough time to acquire the knowledge.
Moreover if ever I come up with an appropriate patch, what would be
the chance to make it upstream???

so I did report and wait

>> I know that we should never generate files in the source dir, but
>> after 3+ years it seems
>> that eclipse is not able (correct me if I'm wrong) to enable source
>> control on "part" of the project.
>
> I'm actually no expert on Eclipse stuff, I basically took over maintainance of
> the generator and I am trying to polish it a bit.

I'm glad you do that, thanks.

> I know this is the biggest issue IMO (although some eclipse users say that the
> svn integration in eclipse is unusable and they use command line for that
> anyways),

I use CVS, SVN and git with Eclipse with not so much trouble, SVN is sometimes
picky but even if I'm not a GUI guy, the patch review is quite
pleasant in Eclipse
using the graphical compare & merge editor.

> and I'd be very happy if this could be solved.

Me too.
I'll dig a little bit on the Eclipse side again, but generating 2
files in the source
does not look like a big deal.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPACK_PACKAGE_DESCRIPTION_FILE for debian

[Eric Noulard]

2011/11/1 Erik Hofman :
>
> Hi,
>
> I'm new to this list and just recently started to use CMake and CPack.
> So far I'm very pleased but there's one thing that I think could use
> some improvement;
>
> As far as I van see (from Wiki) the RPM generating backend of CPack use

You can get up to date doc with

cmake --help-module CPackRPM
same for
cmake --help-module CPackDeb

> CPACK_PACKAGE_DESCRIPTION_FILE if CPACK_RPM_PACKAGE_DESCRIPTION is not
> provided, but the Debian backend does not use
> PACK_PACKAGE_DESCRIPTION_FILE in any way although adding it is just a
> three line patch:
>
>  file(STRINGS description descriptionFile)
>  STRING(REGEX REPLACE ";" " " descriptionFile "${descriptionFile}")
>  SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY ${descriptionFile})

You could even do this is a single line:

file(READ ${CPACK_PACKAGE_DESCRIPTION_FILE} CPACK_PACKAGE_DESCRIPTION_SUMMARY)

Your point is good,
Could you open a bug report,
http://public.kitware.com/Bug/bug_report_page.php

then attach your proposed patch (probably from withing CPackDeb.cmake)

I'll review it and probably merge it soon, since this looks reasonable.
Note however that with CPackRPM you have both

CPACK_RPM_PACKAGE_SUMMARY
and
CPACK_RPM_PACKAGE_DESCRIPTION

whereas for DEB you don't have summary, just:
CPACK_DEBIAN_PACKAGE_DESCRIPTION

thus the difference

> It would be nice if this is the default behavior for all backends.

We would have to review other CPack generators behavior w.r.t.
CPACK_PACKAGE_DESCRIPTION_SUMMARY
CPACK_PACKAGE_DESCRIPTION_FILE

as you can see with RPM and Deb some may use both for the same meaning
some really wants separate usage.

Waiting for your patch :-]
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] To warn or to error out ? - wording and compatiblity

[Eric Noulard]

2011/11/1 Alexander Neundorf :
> Hi,
>
> when using out-of-source builds and the Eclipse CDT project generator, a
> "linked resource" is created in the Eclipse project file, which points to
> CMAKE_SOURCE_DIR, so the user can browse the source directory.
>
> Now, when CMAKE_BINARY_DIR is a subdirectory of CMAKE_SOURCE_DIR (e.g.
> MyProject/build/ ), such a "linked resource" can't be created, and the
> resulting project file still works, but is less usable.
>
> I just added a warning, so that cmake now says:
>
> "-- Configuring done
> CMake Warning in CMakeLists.txt:
>  The build directory is a subdirectory of the source directory.
>
>  This is not supported well by Eclipse.  It is strongly recommended to use a
>  build directory which is not a subdirectory of the source directory.

or may be use:
ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE
option, and import the two projects?

> -- Generating done"
>
> I'm thinking about using FATAL_ERROR instead of warning for this, since the
> resulting project file without that link really feels wrong, and I recommend
> everybody to not build in a subdir of the source dir.
> This would have the effect that a build dir which was working until now does
> not work anymore with the next cmake release, the user would have to create a
> new build dir in some other location.
>
> Would this be acceptable ?

I think a warning is enough, moreover where are we with the
version control integration issue?
http://www.vtk.org/Wiki/Eclipse_CDT4_Generator#Discussion_about_limitations

I just checked that linked resource for the source does not show
version control.
I speak about that issue [again] because when I use eclipse+cmake I usually
do it by hand with a build dir as a subdir of source dir i.e.
source/build
and with hand-crafted
source/.project
source/.cproject
that way I get the source control working as expected and all the file
for the concerned project are in a single dir.

So before making the build dir as a source subdir case FATAL, are you sure
we really don't want to authorize the generatiion of .project
.cproject in the source dir
in this very particular but nervertheless very useful case?

I know that we should never generate files in the source dir, but
after 3+ years it seems
that eclipse is not able (correct me if I'm wrong) to enable source
control on "part"
of the project.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CPACK_PACKAGE_DESCRIPTION_FILE for debian

[Erik Hofman]

Hi,

I'm new to this list and just recently started to use CMake and CPack.
So far I'm very pleased but there's one thing that I think could use
some improvement;

As far as I van see (from Wiki) the RPM generating backend of CPack uses
CPACK_PACKAGE_DESCRIPTION_FILE if CPACK_RPM_PACKAGE_DESCRIPTION is not
provided, but the Debian backend does not use
PACK_PACKAGE_DESCRIPTION_FILE in any way although adding it is just a
three line patch:

 file(STRINGS description descriptionFile)
 STRING(REGEX REPLACE ";" " " descriptionFile "${descriptionFile}")
 SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY ${descriptionFile})

It would be nice if this is the default behavior for all backends.

Regards,

Erik

--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Visual Studio generator and visible projects

[Anton Sibilev]

2.8.6. Just a minute later found that problem was in incorrect FOLDER
property... Sorry!

2011/11/1 Eric Noulard 

> 2011/11/1 Anton Sibilev :
> > Hello! Can you help me, please?
> > I'm generating VS 2010 solution/projects and finally when I open main
> > solution file I can SEE only ALL_BUILD project.
> > All builds fine, all projects exists. But I can't see them and work with
> > sources from them directly. What's wrong?
>
> Which version of CMake are you using?
>
> What does your main CMakeLists.txt looks like?
>
> Did you use any
>   add_executable or add_library in it?
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Visual Studio generator and visible projects

[Eric Noulard]

2011/11/1 Anton Sibilev :
> Hello! Can you help me, please?
> I'm generating VS 2010 solution/projects and finally when I open main
> solution file I can SEE only ALL_BUILD project.
> All builds fine, all projects exists. But I can't see them and work with
> sources from them directly. What's wrong?

Which version of CMake are you using?

What does your main CMakeLists.txt looks like?

Did you use any
   add_executable or add_library in it?
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Visual Studio generator and visible projects

[Anton Sibilev]

Hello! Can you help me, please?
I'm generating VS 2010 solution/projects and finally when I open main
solution file I can SEE only ALL_BUILD project.
All builds fine, all projects exists. But I can't see them and work with
sources from them directly. What's wrong?
--

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_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake