Re: [cmake-developers] GCC x cmake

[J Decker]

On Tue, Sep 19, 2017 at 11:34 AM, Ivam Pretti 
wrote:

> I would like to know what are the advantages or difference when compared
> to GCC compiler.
>
>
I understand from the topic you mean compared to cmake; but the two are two
different things
gcc is a compiler
cmake is a build system that uses compilers
it'd be more meaningful to say make v cmake...

so there is no comparison... definatly an apples and steak comparison (or
orange would at least be fruit)


> --
>
> 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] How to set startup project in Visual Studio

[J Decker]

One might be able to use FILE() to generate a .vcxproj.user if( NOT EXISTS )

This is a version from 2012 project.  ALL_BUILD.vcxproj.user  (it's the
default project. so it's the one i usually set, unless something clever
along these lines happened )



http://schemas.microsoft.com/developer/msbuild/2003;>
  

C:\General\Build\karaway\chatment\output\bin\chatment.exe

C:\General\Build\karaway\chatment\output\bin
WindowsLocalDebugger
  



-
That's not even a very large file to write the whole thing

Another for VS14


http://schemas.microsoft.com/developer/msbuild/2003;>
  

C:\General\Build\sack-x64\Debug_out\core\bin\test.json.parser.exe



C:\General\Build\sack-x64\Debug_out\core\bin
WindowsLocalDebugger
  


---
I guess there's some platform settings that will make it bigger, but done
in a

foreach( target )
  writeProjectUser( target )

shouldn't be too painful...

On Mon, Jun 20, 2016 at 2:11 PM, Stephen Kelly <steve...@gmail.com> wrote:

> J Decker wrote:
>
> > The setting is in a different file that's .vcproj.user (or .user.vcproj)
>
> And there is not one of these for each project() command?
>
> It seems to me that this should either be a GLOBAL property, or the
> documentation which directory to set the DIRECTORY property on. I have no
> idea what the answer is.
>
> 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
>
-- 

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] How to set startup project in Visual Studio

[J Decker]

The setting is in a different file that's .vcproj.user (or .user.vcproj)

and cmake doesn't write that... would be nice if it could at least write
those entiries required... nice thing about xml should be that what's there
can be read and used and filled in with the rest of the settings?  Well I
guess that's really implementation dependant.

On Sun, Jun 19, 2016 at 2:42 PM, Mike Gelfand  wrote:

> Hello,
>
> On 06/18/2016 03:15 PM, Stephen Kelly wrote:
> > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project
> in
> > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the
> > property in the top-level directory, so thanks for that.
> >
> > However, the documentation does not say which directory to set it in, or
> why
> > it is a DIRECTORY property.
> >
> > Why is this not a GLOBAL property?
> My guess would be because CMake generates .sln file for each project()
> call (e.g. if you have additional project() calls in subdirectories
> apart from the top-level one), and then for each .sln file it would be
> possible to specify different startup [VS] project. So it's not exactly
> a directory, but a project property I would say, but there're no
> "project properties" in CMake.
>
> Regards,
> Mike
> --
>
> 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] CMake alternative language

[J Decker]

On Thu, Jan 14, 2016 at 3:09 PM, Jean-Michaël Celerier
 wrote:
> The problem is doing :
>
> list(LENGTH MyList NumList)
> math(EXPR MaxItList ${NumList}-1)
>
> foreach(i RANGE ${MaxItList})
> list(GET MyOtherListOfSameSizeThanMyList ${i} Element)
> foobazify(${Element})
> endforeach()
>
Probably a bad exmple, since you're not using MyList or i that simplifies to

foreach( Element ${MyOtherListOfSameSizeThanMylist} )
foobazify( ${Element} )
endforeach()

> instead of :
>
> for i in range(0, MyList.size):
> foobazifiy(MyOtherListOfSameSizeThanMyList[i])
>
>
>
>
>
> On Thu, Jan 14, 2016 at 2:08 PM, Charles Huet 
> wrote:
>>
>> As long as CMake embeds everything that is required, I don't see the
>> additional pain (since this is what it already does with the CMake
>> language).
>>
>>
>> Le jeu. 14 janv. 2016 à 13:35, Jean-Michaël Celerier
>>  a écrit :
>>>
>>>
>>> On Wed, Jan 13, 2016 at 10:21 PM, Alexander Neundorf 
>>> wrote:


 My personal opinion: if the full power of python would be available, the
 build
 scripts would quickly turn into real programs, because programmers would
 be
 tempted to do so if all of python would be available. Then developers
 would
 have to understand two programs: the program itself, and the "build
 program".
>>>
>>>
>>> The problem is when you have to do a real program for your build system
>>> anyways (which occurs one day or another for any large enough project I
>>> guess).
>>> Currently it's a real pain (but it'd be even more painful to have to ship
>>> Python / Bash / $script_language as part of your build system).
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake-developers
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: 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] CMake alternative language

[J Decker]

My stumbling blocks are the use of keywords instead of operators...

if( Something == ${SomeOtherThing} )
vs
if( Something STREQUAL ${SomeOtherTHing} )

It might be nice if the operator '=' could be used in addition to the
function SET()

SET( a something )
becomes
A = something

Was gong to say 'I understand that it would be difficult' but ... not
really, if the first word isn't a 'keyword' (Function/Macro name) then
if the next token is a = instead of a ( then assume it's a SET 

-
Re: "no return values for functions"  that's not true... this script
sets the return value just fine...

---
cmake_minimum_required( VERSION 3.0 )

macro( SomeFunc ReturnVal )
   set( ${ReturnVal} SomeResult )
endmacro( SomeFunc )

SomeFunc( RetVal )
message( "and we have a result of " ${RetVal} )

output : and we have a result of SomeResult

-
J/K : I think the alternative language should be LISP; oh wait that's
already what it is. other than the function is outside of the parens

One of the last comments mentioned something about the named
parameters passed to methods like

SET_TARGET_PROPERTIES(${project} PROPERTIES
  FOLDER utils
  COMPILE_DEFINTIIONS "SomeOtherSyms"
)

Is at first a little confusing... but at least I don't have some
required order where I have to isnert a bunch of blank ',,' to get
to the option I want to use.

It might be nice if there were methods to define your own syntax for
these things for use in passing options to MACRO where as you iterate
through the ARGN members it can trigger some sort of state table
lookup/dispatch... but then I really don't have a use for such a thing
in the reality of switching to cmake maybe 5 years ago.

Re: Profile-ability of CMake.  I haven't yet found anywhere that I
would blame any part of the build process slowness on CMAKE, but
rather on the build tools themselves (CygWin or MinGW for instances).
Although... there is One project I often rebuild (OpenAL) which uses a
bunch of CHECK_FUNCTION_EXISTS(snprintf HAVE_SNPRINTF) which seems to
be pretty slow.   But Really, I think the target rules would be better
to test CMAKE_COMPILER_IS_ and WIN32/UNIX variables to get that
result.  There's certainly less permutations to test that way than
testing for each function that might exist; since the variations are
limited to environments (each generator) with perhaps a minor off case
for some toolchains.  But I guess that was put in to satisy autotool
people coming to a different build system.
-- 

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] Get the list of files that will be installed by CMake?

[J Decker]

building the list of things to install and then using that list... the
other way no.


On Thu, Nov 26, 2015 at 11:33 AM, Robert Goulet
 wrote:
> Hi all,
>
>
>
> Is there a way in CMake to get the list of files that are going to be
> installed when we use the install command? Some kind of
> CMAKE_INSTALL_FILES_LIST or something like that? We would need to get that
> list of files so we can add them as “Content” to our Windows 10 UWP project
> (otherwise they are not part of the deployment).
>
>
>
> Thanks!
>
>
> --
>
> 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] Antwort: Re: Specifying a VS installation path explicitly

[J Decker]

Actually most of the logic is not in the source but in the modules
~/cmake/modules/platform/Windows-MSVC.cmake

can also use cmake --trace with maybe a simple cmake file to see what
it might use...

On Tue, Oct 27, 2015 at 9:59 AM, Brad King  wrote:
> On 10/27/2015 12:50 PM, Johannes Asal wrote:
>> I was actually asking for the environment variable dependencies.
>
> Actually I do not think the VS 2010 generator actually has any environment
> variable dependencies.  It may be that VS itself needs some environment
> variables set.  This is why seeing the actual error logs may help.
>
> -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] script mode current directory

[J Decker]

On Fri, Oct 2, 2015 at 4:40 AM, Tamás Kenéz  wrote:
> In script mode it seems that all the CMAKE_[CURRENT_](BINARY|SOURCE)_DIR
> variables are set to the current working directory.
>

if CMAKE_[CURRENT]_SOURCE_DIR is current directory; you're doing
something wrong :)   That implies that you're doing an in-source build
which is actually less than supported.

cmake --build  allows specifying where the output goes... so; no,
it's prossible that it will never be the 'current' directory.

> Is this something we can rely on and it could be added to the documentation?
>
> Tamas
>
> --
>
> 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] C# support?

[J Decker]

On Mon, Jun 29, 2015 at 10:05 AM, Brad King brad.k...@kitware.com wrote:

 On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
  Does it have a realistic chance to be accepted for upstream

 Yes, so long as it comes with proper tests and is not too intrusive
 on the overall design/implementation of CMake.

 In order to enable use of C# sources we should get

  enable_language(CSharp)

 to work.  This is likely straightforward with the VS generators.

 One question is how things should be done for the Makefile and
 Ninja generators.  For these we need to construct command line
 invocations of the compiler.  I'm not very familiar with C#.
 Does it need separate compilation with dependencies or should one
 simply invoke the compiler with the entire list of sources in
 a response file or something?


the command line tool is 'mcs' (mono)
http://linux.die.net/man/1/mcs

and csc for .NET (windows)
https://msdn.microsoft.com/en-us/library/78f4aasd.aspx
(does support response file with @file; from running csc /?)

it goes from source to .dll or .exe without .obj inbetween.

can compile with C# itself... but I guess there's no command line tool from
.NET itself (looks like it comes from visual studio)... something like
Power Shell can instance a compiler and build output.
(wonder if that was part of the sources includes in the .net source release)


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

-- 

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] Is there a way to avoid LOCATION property with Qt5?

[J Decker]

many places that you would use LOCATION you can use generator expressions
http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html

$TARGET_FILE_DIR:targetname

On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:

 Hi Nils:

 Thanks for your quick reply.  More below in context.


 On 2015-04-28 08:45+0200 Nils Gladitz wrote:

  On 04/28/2015 08:00 AM, Alan W. Irwin wrote:

 The Qt5 cmake documentation at
 http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me
 to before states you should use the LOCATION property of targets to
 determine the actual path to libraries. The PLplot build system
 requires those locations so it can transform them into the -L and -l
 form required to generate its pkg_config *.pc files.

 Some time ago I got this process to work fine for CMP0026 OLD and Qt5,
 but
 what is the alternative I should use for the CMP0026 NEW case (which
 disallows using the LOCATION property for targets)?

 Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for
 a CMP0026 NEW solution that works for that version or above for Qt5.


 CMP0026 only applies to build targets.

 The location of build targets is still in flux during configuration which
 is why getting the location of those during configuration time is unsafe.

 For imported targets this does not apply since their location is fixed.


 OK.  Thanks, for pointing that out.  Could you make that more obvious
 in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e.
 change the summary line from

 Disallow use of the LOCATION target property.

 ==

 Disallow use of the LOCATION property for build targets.

 I took that summary line to mean exactly what it said and just plain
 missed the reference to build targets that is in the first paragraph
 of that documenation.


 For which configuration LOCATION returns isn't defined but I suppose that
 may not matter for pkg-config.

 Otherwise you may want to look into LOCATION_CONFIG.


 I don't understand exactly what you mean by configuration LOCATION
 returns.  From what you said that term means something different from
 LOCATION_CONFIG and in any case is not relevant to my use case of
 generating pkg-config *.pc files with our build system, but I am
 nevertheless curious about what you meant.)

 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state
 implementation for stellar interiors (freeeos.sf.net); the Time
 Ephemerides project (timeephem.sf.net); PLplot scientific plotting
 software package (plplot.sf.net); the libLASi project
 (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
 and the Linux Brochure Project (lbproject.sf.net).
 __

 Linux-powered Science
 __
 --

 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] [Review request] Topic install_CMAKE_INSTALL_RELATIVE

[J Decker]

On Mon, Dec 22, 2014 at 1:25 PM, Brad King brad.k...@kitware.com wrote:

 On 12/22/2014 03:28 PM, Domen Vrankar wrote:
  Maybe others will disagree but to be quite honest I myself don't think
  that CMAKE_INSTALL_RELATIVE variable would be the right solution... I
  myself prefer to write install commands with relative paths and I
  guess that something like that should be fixed in CMakeLists.txt and
  contributed to projects that use absolute paths and not add a new
  variable for doing this...

 I agree.  If a project uses absolute install paths that means its
 authors have not thought about making relocatable packages.  There
 could be many other problems with making such projects relocatable
 other than just install rules.


THere's not a problem with relative install paths; why were they passed as
absolute?  Just apply a pre-filter on your side like if( matches
${destpath} ${cmake_install_prefix}  ) subst it out.  All paths are
relative to start with; and seems like a corruption to have an abosolute
path


 -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] CMake 3.1 Android - generator expressions and output names

[J Decker]

Set_source_files_properties( *test2.c** PROPERTIES** LANGUAGE CXX** )*

http://www.cmake.org/pipermail/cmake/2008-July/022647.html

On Tue, Dec 16, 2014 at 5:45 AM, Dmitry Polyanitsa dpolyani...@nvidia.com
wrote:

 Yes, that's the one.

 Nsight Tegra will upgrade the projects without a prompt, but only starting
 with the next version number increase.

 -Dmitry

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: Tuesday, December 16, 2014 4:30 PM
 To: Robert Goulet
 Cc: Dmitry Polyanitsa; cmake-developers@cmake.org
 Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions
 and output names

 On 12/16/2014 06:58 AM, Dmitry Polyanitsa wrote:
  3.0r4 has added a popup when opening the solution in Visual Studio
  stating that the project files generated needs to be upgraded.
 
  I'm sure I've submitted a patch for this - please try updating CMake

 IIUC the patch was this one:

  VS: Change Nsight Tegra 2.0 Project Revision Number from 8 to 9
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3c87f1

 and is available in 3.1.0-rc3.

 However, CMake cannot predict future version numbers, so it writes a
 NsightTegraUpgradeOnceWithoutPrompt element into the project file.
 Nsight Tegra is supposed to upgrade such projects without any popup.

 -Brad


 ---
 This email message is for the sole use of the intended recipient(s) and
 may contain
 confidential information.  Any unauthorized review, use, disclosure or
 distribution
 is prohibited.  If you are not the intended recipient, please contact the
 sender by
 reply email and destroy all copies of the original message.

 ---
 --

 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

[cmake-developers] Revert watcom symfile option

[J Decker]

Recently watcom link options were changed to generate .sym files instead of
building the debug information into targets.  The rules used to create the
.sym name for some files are kind of bad, and there is no way to set the
symbol file name of a target; so it is better to revert that change.  It's
easy to run 'wstrip *' if the symbols need to be stripped, but it's very
difficult to get the right names for the .sym files to install with
debug/rel_with_deb_info targets
tried to add generator expressions to the flags to build a better symfile
name; but they don't get resolved correctly

this diff is based against current git sources

modifies share/modules/platform/windows-wcl386.cmake
 Modules/Platform/Windows-wcl386.cmake | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modules/Platform/Windows-wcl386.cmake 
b/Modules/Platform/Windows-wcl386.cmake
index ac410de..88f9bf7 100644
--- a/Modules/Platform/Windows-wcl386.cmake
+++ b/Modules/Platform/Windows-wcl386.cmake
@@ -18,8 +18,8 @@ set(CMAKE_CREATE_CONSOLE_EXE system nt )
 set(CMAKE_SHARED_LINKER_FLAGS_INIT system nt_dll)
 set(CMAKE_MODULE_LINKER_FLAGS_INIT system nt_dll)
 foreach(type SHARED MODULE EXE)
-  set(CMAKE_${type}_LINKER_FLAGS_DEBUG_INIT debug all opt map, symfile)
-  set(CMAKE_${type}_LINKER_FLAGS_RELWITHDEBINFO_INIT debug all opt map, 
symfile)
+  set(CMAKE_${type}_LINKER_FLAGS_DEBUG_INIT debug all opt map)
+  set(CMAKE_${type}_LINKER_FLAGS_RELWITHDEBINFO_INIT debug all opt map)
 endforeach()
 
 set(CMAKE_C_COMPILE_OPTIONS_DLL -bd) # Note: This variable is a ';' 
separated list
-- 

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] Watcom updates in 3.1 break linking usable code

[J Decker]

wlink uses the option 'system nt_dll' if it builds a DLL; if this is not
specified, the resulting file generates exceptions.

This was moved from ...

/  modules/platform/windows-wcl386.cmake --
set(CMAKE_CXX_CREATE_SHARED_LIBRARY
 wlink ${CMAKE_START_TEMP_FILE} ${CMAKE_WLINK_QUIET} name TARGET
LINK_FLAGS option implib=TARGET_IMPLIB file {OBJECTS}
LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})

/-- used to be - /
set(CMAKE_CXX_CREATE_SHARED_MODULE
 wlink ${CMAKE_START_TEMP_FILE} system nt_dll  ${CMAKE_WLINK_QUIET} name
'TARGET_UNQUOTED' LINK_FLAGS option implib=TARGET_IMPLIB option
caseexact  file {OBJECTS} LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})


... to a variable

CMAKE_SHARED_LINKER_FLAGS_INIT

but I don't see the latter flag ever being used.

So the generator does not output 'system nt_dll' when building shared
library targets.
-- 

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] Watcom updates in 3.1 break linking usable code

[J Decker]

*regarding prior issue; might be because I had not cleaned properly when
changing versions of cmake; because with fix and reinstall, I ended up
duplicating the system nt_dll option *

Should add version ...
also in windows-wcl386.cmake

if(NOT _CMAKE_WATCOM_VERSION)
  set(_CMAKE_WATCOM_VERSION 1)
  if(CMAKE_C_COMPILER_VERSION)
set(_compiler_version ${CMAKE_C_COMPILER_VERSION})
set(_compiler_id ${CMAKE_C_COMPILER_ID})
  else()
set(_compiler_version ${CMAKE_CXX_COMPILER_VERSION})
set(_compiler_id ${CMAKE_CXX_COMPILER_ID})
  endif()
  set(WATCOM16)
  set(WATCOM17)
  set(WATCOM18)
  set(WATCOM19)
  set(WATCOM20)
  if(${_compiler_id} STREQUAL OpenWatcom)
if(${_compiler_version} VERSION_LESS 1.7)
  set(WATCOM16 1)
endif()
if(${_compiler_version} VERSION_EQUAL 1.7)
  set(WATCOM17 1)
endif()
if(${_compiler_version} VERSION_EQUAL 1.8)
  set(WATCOM18 1)
endif()
if(${_compiler_version} VERSION_EQUAL 1.9)
  set(WATCOM19 1)
endif()
if(${_compiler_version} VERSION_EQUAL 2.0)
  set(WATCOM20 1)
endif()
  endif()
endif()


On Sat, Nov 1, 2014 at 4:03 PM, J Decker d3c...@gmail.com wrote:

 wlink uses the option 'system nt_dll' if it builds a DLL; if this is not
 specified, the resulting file generates exceptions.

 This was moved from ...

 /  modules/platform/windows-wcl386.cmake --
 set(CMAKE_CXX_CREATE_SHARED_LIBRARY
  wlink ${CMAKE_START_TEMP_FILE} ${CMAKE_WLINK_QUIET} name TARGET
 LINK_FLAGS option implib=TARGET_IMPLIB file {OBJECTS}
 LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})

 /-- used to be - /
 set(CMAKE_CXX_CREATE_SHARED_MODULE
  wlink ${CMAKE_START_TEMP_FILE} system nt_dll  ${CMAKE_WLINK_QUIET} name
 'TARGET_UNQUOTED' LINK_FLAGS option implib=TARGET_IMPLIB option
 caseexact  file {OBJECTS} LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})
 

 ... to a variable

 CMAKE_SHARED_LINKER_FLAGS_INIT

 but I don't see the latter flag ever being used.

 So the generator does not output 'system nt_dll' when building shared
 library targets.

-- 

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] OpenWatcom wMake and VERBOSE=1

[J Decker]

VERBOSE=1 only triggers the first level to be verbose in a make... any
subsequent call to wmake passes '-s' option and not VERBOSE=1
continuously...

I'm not sure where the '-s' option on wmake is coming from, browsed the
code a little... but it'd be kind of nice if this feature worked.
-- 

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] Install quiet option

[J Decker]

cleaned up patch and investigated what symlink install does; this should
work for that too...
updated http://public.kitware.com/Bug/view.php?id=13761#bugnotes


On Fri, Jun 13, 2014 at 2:20 PM, J Decker d3c...@gmail.com wrote:

 in the vein of http://www.cmake.org/Wiki/CMake_Useful_Variables
 CMAKE_INSTALL_ALWAYS
 patch adds CMAKE_INSTALL_QUIET

 This bypasses 'Up-to-date:'  on file that are up to date
 and 'Installing' on directories that already exist and are directories.

 There are 3 places that call 'ReportCopy' the third is when symlinks are
 made; I have no way to test an appropriate modification to bypass it's
 status when really no action taken.

 Not sure header on diff is appropriate for applying

-- 

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] Install quiet option

[J Decker]

Hmmm... environment variable doens't work very cleanly...
I have another idea

set_property(GLOBAL PROPERTY QUIET_INSTALL ON )

sort of like 'set_property(GLOBAL PROPERTY USE_FOLDERS On) 


which should be
+
cmSystemTools::IsOn(this-Makefile-GetCMakeInstance()-GetProperty(QUIET_INSTALL));

instead of
+  cmSystemTools::IsOn(cmSystemTools::GetEnv(CMAKE_INSTALL_QUIET));

but GetProperty() always returns NULL?




On Mon, Jun 16, 2014 at 7:41 AM, J Decker d3c...@gmail.com wrote:

 cleaned up patch and investigated what symlink install does; this should
 work for that too...
 updated http://public.kitware.com/Bug/view.php?id=13761#bugnotes


 On Fri, Jun 13, 2014 at 2:20 PM, J Decker d3c...@gmail.com wrote:

 in the vein of http://www.cmake.org/Wiki/CMake_Useful_Variables
 CMAKE_INSTALL_ALWAYS
 patch adds CMAKE_INSTALL_QUIET

 This bypasses 'Up-to-date:'  on file that are up to date
 and 'Installing' on directories that already exist and are directories.

 There are 3 places that call 'ReportCopy' the third is when symlinks are
 made; I have no way to test an appropriate modification to bypass it's
 status when really no action taken.

 Not sure header on diff is appropriate for applying



-- 

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] Install quiet option

[J Decker]

I guess at install the only option is to get values from the environment...
since the this-Makefile has like nothing from CMakeCache in it... using
GetSafeDefinition results blank for similar values... and I guess cmake
global properties aren't actually kept past generation, since 'USE_FOLDERS'
doesn't appear anywhere in my build directories...

crazy.


On Mon, Jun 16, 2014 at 10:48 AM, J Decker d3c...@gmail.com wrote:

 Hmmm... environment variable doens't work very cleanly...
 I have another idea

 set_property(GLOBAL PROPERTY QUIET_INSTALL ON )

 sort of like 'set_property(GLOBAL PROPERTY USE_FOLDERS On) 


 which should be
 +
 cmSystemTools::IsOn(this-Makefile-GetCMakeInstance()-GetProperty(QUIET_INSTALL));

 instead of
 +  cmSystemTools::IsOn(cmSystemTools::GetEnv(CMAKE_INSTALL_QUIET));

 but GetProperty() always returns NULL?




 On Mon, Jun 16, 2014 at 7:41 AM, J Decker d3c...@gmail.com wrote:

 cleaned up patch and investigated what symlink install does; this should
 work for that too...
 updated http://public.kitware.com/Bug/view.php?id=13761#bugnotes


 On Fri, Jun 13, 2014 at 2:20 PM, J Decker d3c...@gmail.com wrote:

 in the vein of http://www.cmake.org/Wiki/CMake_Useful_Variables
 CMAKE_INSTALL_ALWAYS
 patch adds CMAKE_INSTALL_QUIET

 This bypasses 'Up-to-date:'  on file that are up to date
 and 'Installing' on directories that already exist and are directories.

 There are 3 places that call 'ReportCopy' the third is when symlinks are
 made; I have no way to test an appropriate modification to bypass it's
 status when really no action taken.

 Not sure header on diff is appropriate for applying




-- 

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] Install quiet option

[J Decker]

in the vein of http://www.cmake.org/Wiki/CMake_Useful_Variables
CMAKE_INSTALL_ALWAYS
patch adds CMAKE_INSTALL_QUIET

This bypasses 'Up-to-date:'  on file that are up to date
and 'Installing' on directories that already exist and are directories.

There are 3 places that call 'ReportCopy' the third is when symlinks are
made; I have no way to test an appropriate modification to bypass it's
status when really no action taken.

Not sure header on diff is appropriate for applying
--- source\cmFileCommand.cxxMon Jun  9 08:52:04 2014
+++ source\cmFileCommand.cxx.newFri Jun 13 14:05:40 2014
@@ -964,6 +964,7 @@
 UseGivenPermissionsFile(false),
 UseGivenPermissionsDir(false),
 UseSourcePermissions(true),
+InstallQuiet(false),
 Doing(DoingNone)
 {
 }
@@ -1100,6 +1101,7 @@
   bool UseGivenPermissionsFile;
   bool UseGivenPermissionsDir;
   bool UseSourcePermissions;
+  bool InstallQuiet;
   std::string Destination;
   std::vectorstd::string Files;
   int Doing;
@@ -1611,7 +1615,10 @@
 MatchProperties const match_properties)
 {
   // Inform the user about this directory installation.
-  this-ReportCopy(destination, TypeDir, true);
+  if( !this-InstallQuiet 
+|| !cmSystemTools::FileExists(destination) 
+|| !cmSystemTools::FileIsDirectory(destination) )
+ this-ReportCopy(destination, TypeDir, true);
 
   // Make sure the destination directory exists.
   if(!cmSystemTools::MakeDirectory(destination))
@@ -1706,6 +1713,9 @@
 {
 // Installation does not use source permissions by default.
 this-UseSourcePermissions = false;
+// Check whether to report all directories and up-to-date-files or only 
those created/installed.
+this-InstallQuiet =
+  cmSystemTools::IsOn(cmSystemTools::GetEnv(CMAKE_INSTALL_QUIET));
 // Check whether to copy files always or only if they have changed.
 this-Always =
   cmSystemTools::IsOn(cmSystemTools::GetEnv(CMAKE_INSTALL_ALWAYS));
@@ -1740,7 +1750,8 @@
 {
 std::string message = (copy? Installing:  : Up-to-date: );
 message += toFile;
-this-Makefile-DisplayStatus(message.c_str(), -1);
+if( copy || !this-InstallQuiet )
+  this-Makefile-DisplayStatus(message.c_str(), -1);
 if(type != TypeDir)
   {
   // Add the file to the manifest.
-- 

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] OpenBSD without SONAME

[J Decker]

 CMake would much rather use full paths rather than -L/-l because of
 ambiguity problems.


 While I can see that; I can get around abguity by ordering the order of -L
entries... like if one was buliding an upgrade to an already installed
library, one would want the current version to link against what's being
built not what's installed

It would appear that LD has no internal default paths so they're all
specified on the command line or in linker scripts
http://stackoverflow.com/questions/9922949/how-to-print-the-ldlinker-search-path

So I personally didn't understand why it was specifying full path to .so's
anyway.

I think maybe there was one-off systems that were considered 'standard'
when developing these things(should have been the exception not the
rule)  And maybe I'm way off base
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] cleanup Watcom Windows configuration

[J Decker]

On Thu, Mar 27, 2014 at 7:47 AM, Jiri Malak malak.j...@gmail.com wrote:

 I atached patch which cleanup Watcom Windows configuration

 It includes following changes.

 remove Watcom linker caseexact options already defined in linker system
 definition


what do you mean 'defined in linker system definition'?  This option
caseexact was previously not present and had to be added.

Functions 'scale' and 'Scale' would collide and mislink.



 use win_dll system for SHARED_LIBRARY and SHARED_MODULE
 use explicit target definition -bt=.. option for proper initialization of
 compiler Windows
 environment (predefined macros)
 reorganize compiler options to global and configuration specific part
 correct debug related compilers options and linker options
 use -s option to optimize out stack checking code for release version
 --

 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/cgi-bin/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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Building executables as libraries

[J Decker]

I dunno; again, there isn't a magic call to 'main' which sets up the
approriate call... there could be, but it would be project specific

It would make more sense to make a macro like
add_program
which would hide the if; and would be an easy conversion from
add_executable to add_program 

still think at this point it's up to the developer and that having cmake
just produce dll's instead of EXE's isn't quite enough
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Building executables as libraries

[J Decker]

and (sorry for double reply) having add_executable always build as a
library means I can't build real executables... if it did it based on the
WIN32 flag (or equivalent0 it would be better


On Wed, Mar 26, 2014 at 7:17 AM, J Decker d3c...@gmail.com wrote:

 I dunno; again, there isn't a magic call to 'main' which sets up the
 approriate call... there could be, but it would be project specific

 It would make more sense to make a macro like
 add_program
 which would hide the if; and would be an easy conversion from
 add_executable to add_program 

 still think at this point it's up to the developer and that having cmake
 just produce dll's instead of EXE's isn't quite enough

-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0014827]: Preprocessor definitions for x64 projects are not correct on Windows Platform.

[J Decker]

Personally I liked that win32 was defined still, since that caused the
least disruption to existing code.  I have additional tests to enable 64bit
by testing for cmake_cl_64 then more generically with CMAKE_SIZEOF_VOID_P

since the API doesn't really change, it still really looks like a win32
system.


On Mon, Mar 24, 2014 at 4:13 AM, Mantis Bug Tracker 
man...@public.kitware.com wrote:


 The following issue has been SUBMITTED.
 ==
 http://public.kitware.com/Bug/view.php?id=14827
 ==
 Reported By:Vikas Pachisia
 Assigned To:
 ==
 Project:CMake
 Issue ID:   14827
 Category:   Development
 Reproducibility:always
 Severity:   major
 Priority:   high
 Status: new
 ==
 Date Submitted: 2014-03-24 07:13 EDT
 Last Modified:  2014-03-24 07:13 EDT
 ==
 Summary:Preprocessor definitions for x64 projects are
 not
 correct on Windows Platform.
 Description:
 When trying to make a x64 windows project using CMake it always assigns the
 platform defines as WIN32 while it should be assigning the platform define
 as
 WIN64.

 Steps to Reproduce:
 1. Try to make a simple basic x64 project that will create a visual studio
 solution file (.sln) file.
 2. Open the solution file that contains the x64 project.
 3. Check the Project Properties for C++ - Preprocessor - Preprocessor
 Definitions
 4. You can see WIN32 as the preprocessor defines where as it should be
 WIN64.

 Additional Information:
 The following change can fix this for most projects:

 1. Open the CMake file:
 C:\Program Files (x86)\CMake
 2.8\share\cmake-2.8\Modules\Platform\Windows-MSVC.cmake

 2. Search for the code:
 if(MSVC_C_ARCHITECTURE_ID MATCHES 64 OR MSVC_CXX_ARCHITECTURE_ID MATCHES
 64)
   set(CMAKE_CL_64 1)
 else()
   set(CMAKE_CL_64 0)
 endif()
 if(CMAKE_FORCE_WIN64 OR CMAKE_FORCE_IA64)
   set(CMAKE_CL_64 1)
 endif()

 3. Add the following new code after the end if mentioned above:
 if(CMAKE_CL_64)
 set(WIN64 1)
 else()
 set(WIN32 1)
 endif()

 4. Search for 'set(_PLATFORM_DEFINES /DWIN32)'
 5. Replace the above line with the following code:
 if(CMAKE_CL_64)
 set(_PLATFORM_DEFINES /DWIN64)
 else()
 set(_PLATFORM_DEFINES /DWIN32)
 endif()
 ==

 Issue History
 Date ModifiedUsername   FieldChange
 ==
 2014-03-24 07:13 Vikas Pachisia New Issue
 2014-03-24 07:13 Vikas Pachisia File Added: Windows-MSVC.cmake

 ==

 --

 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/cgi-bin/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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Building executables as libraries

[J Decker]

I think this is impractical... the native activituy doesn't provide a hood
to call 'main' and while you may have special code to treat main as an
export and dynamically load it, actually stubstitute the single program
with a loader dll and the program as a DLL, and the loader DLL has custom
code depending on the package. The reason to do this is to support a
package that support multiple entry points; the library and class name must
be different to have a separate launcher icon


On Fri, Mar 21, 2014 at 8:44 AM, Stephen Kelly steve...@gmail.com wrote:


 Hi,

 For many years, KDE (on UNIX) has had a system of launching executables by
 forking the kdeinit process and loading the application code with dlopen.
 This allows avoiding the startup overhead of initializing Qt etc for each
 process which is started.

 Launching the konqueror application from a UI such as the KMenu or KRunner
 will run something like 'kwrapper4 konqueror', which uses D-Bus to tell
 klauncher, which serializes such requests and uses a socket connection to
 kdeinit to trigger it to do the fork+dlopen.

 For convenience, KDE creates both the dlopen'able library and a separate
 executable which links to the library so that the user can also just
 execute
 'konqueror' on the command line, bypassing the kdeinit system.


 https://projects.kde.org/projects/frameworks/kinit/repository/revisions/master/entry/KF5InitMacros.cmake#L14

 Maemo used the same trick:

  http://katastrophos.net/harmattan-dev/html/guide/html/qtboost.html


 https://maemo.gitorious.org/maemo-af/maemo-launcher-qtbooster46-fremantle/source/158a316db5387752bd0be9655ee2b85b6dcc3999:README

 I think BB10 can use the same trick:

  http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0ffea110c1/
  http://devblog.blackberry.com/2012/12/cascades-project-zygote/

 Android requires native code to be loaded from java as a shared library
 using

 System.loadLibrary(TestCMake);

 to load a library called libTestCMake.so. The android packaging system
 won't
 even package a file if it does not have the .so extension. Console-only
 applications on Android may be regular executables.



 Should we try to add first-class support to CMake for building shared
 libraries from CMake code like

  add_executable(...)

 somehow? There would probably need to be some properties to control it, but
 I wanted to raise the idea.

 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/cgi-bin/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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake contribution for Open Watcom (patch)

[J Decker]

That continues to be broken for what we talked about in the newsgroup;

The wlib should be removed *???*


On Fri, Feb 28, 2014 at 9:57 AM, Jiri Malak malak.j...@gmail.com wrote:

 Hi,

 I would like contribute to CMake for Open Watcom Toolchain.
 Now only WIN32 host and target is supported.
 I plan to add cross-compilation configuration for all supported hosts and 
 target.
 By example enable user on Linux cross compile for DOS/WIN16/win32/OS2
 etc.

 I enclosed first fix for existing bug in OW support.

 From 503538874023eeddac975eb09660d59f4067fcd9 Mon Sep 17 00:00:00 2001
 From: Jiri Malak malak.j...@gmail.com 
 http://192.168.0.2/posta/src/compose.php?send_to=malak.jiri%40gmail.com
 Date: Fri, 28 Feb 2014 18:21:52 +0100
 Subject: [PATCH] Open Watcom Module Windows-wcl386.cmake fix

 fix incorrect quoting of library name, now it is double quote instead of 
 incorrect
 single quote
 ---
  Modules/Platform/Windows-wcl386.cmake | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Modules/Platform/Windows-wcl386.cmake
 b/Modules/Platform/Windows-wcl386.cmake
 index 8a03b29..329e6f0 100644
 --- a/Modules/Platform/Windows-wcl386.cmake
 +++ b/Modules/Platform/Windows-wcl386.cmake
 @@ -40,7 +40,7 @@ set (CMAKE_C_STANDARD_LIBRARIES_INIT library clbrdll.lib 
 library
 plbrdll.lib  l
  set (CMAKE_CXX_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT})

  set(CMAKE_C_CREATE_IMPORT_LIBRARY
 -  wlib -c -q -n -b TARGET_IMPLIB +'TARGET_UNQUOTED')
 +  wlib -c -q -n -b TARGET_IMPLIB +TARGET_QUOTED)
  set(CMAKE_CXX_CREATE_IMPORT_LIBRARY ${CMAKE_C_CREATE_IMPORT_LIBRARY})

  set(CMAKE_C_LINK_EXECUTABLE
 @@ -78,7 +78,7 @@ set(CMAKE_C_CREATE_SHARED_LIBRARY 
 ${CMAKE_CXX_CREATE_SHARED_LIBRARY})
  set(CMAKE_C_CREATE_SHARED_MODULE ${CMAKE_CXX_CREATE_SHARED_MODULE})

  # create a C++ static library
 -set(CMAKE_CXX_CREATE_STATIC_LIBRARY  wlib ${CMAKE_LIB_QUIET} -c -n -b
 'TARGET_UNQUOTED'
 LINK_FLAGS OBJECTS )
 +set(CMAKE_CXX_CREATE_STATIC_LIBRARY  wlib ${CMAKE_LIB_QUIET} -c -n -b
 TARGET_QUOTED OBJECTS )

  # create a C static library
  set(CMAKE_C_CREATE_STATIC_LIBRARY ${CMAKE_CXX_CREATE_STATIC_LIBRARY})
 --
 1.8.0.msysgit.0

 Regards

 Jiri



 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake contribution for Open Watcom (patch)

[J Decker]

THere is 'toolchain' support sort-of in cmake, for selecting targets

Something else that cmake building is lacking is a working RC compiler
default...

 SET( CMAKE_RC_COMPILER rc )

# I dunno; something about floating point, not sure if it's required it's
from long ago... probably because I was linking to stdio sscanf but didn't
use a string that had a %g or %f in it so floating point support wasn't
linkin...
 set( ExtraFlags ${ExtraFlags} /fp5 /fpi87 )


 # this flag is for build dll?  emit DllRuntime startup link
#set( LibraryExtraFlags -bd )


 set( ConsoleProgramExtraFlags -bc )


 set( WindowsProgramExtraFlags -bg )


when adding 'add_executable( target optional WIN32 ... ) '
there is a marker for wheter to include console or windows runtime (select
main or winmain entry points)

and for add_library( target optional SHARED ... ) should add -bd

yes?



On Fri, Feb 28, 2014 at 9:57 AM, Jiri Malak malak.j...@gmail.com wrote:

 Hi,

 I would like contribute to CMake for Open Watcom Toolchain.
 Now only WIN32 host and target is supported.
 I plan to add cross-compilation configuration for all supported hosts and 
 target.
 By example enable user on Linux cross compile for DOS/WIN16/win32/OS2
 etc.

 I enclosed first fix for existing bug in OW support.

 From 503538874023eeddac975eb09660d59f4067fcd9 Mon Sep 17 00:00:00 2001
 From: Jiri Malak malak.j...@gmail.com 
 http://192.168.0.2/posta/src/compose.php?send_to=malak.jiri%40gmail.com
 Date: Fri, 28 Feb 2014 18:21:52 +0100
 Subject: [PATCH] Open Watcom Module Windows-wcl386.cmake fix

 fix incorrect quoting of library name, now it is double quote instead of 
 incorrect
 single quote
 ---
  Modules/Platform/Windows-wcl386.cmake | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Modules/Platform/Windows-wcl386.cmake
 b/Modules/Platform/Windows-wcl386.cmake
 index 8a03b29..329e6f0 100644
 --- a/Modules/Platform/Windows-wcl386.cmake
 +++ b/Modules/Platform/Windows-wcl386.cmake
 @@ -40,7 +40,7 @@ set (CMAKE_C_STANDARD_LIBRARIES_INIT library clbrdll.lib 
 library
 plbrdll.lib  l
  set (CMAKE_CXX_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT})

  set(CMAKE_C_CREATE_IMPORT_LIBRARY
 -  wlib -c -q -n -b TARGET_IMPLIB +'TARGET_UNQUOTED')
 +  wlib -c -q -n -b TARGET_IMPLIB +TARGET_QUOTED)
  set(CMAKE_CXX_CREATE_IMPORT_LIBRARY ${CMAKE_C_CREATE_IMPORT_LIBRARY})

  set(CMAKE_C_LINK_EXECUTABLE
 @@ -78,7 +78,7 @@ set(CMAKE_C_CREATE_SHARED_LIBRARY 
 ${CMAKE_CXX_CREATE_SHARED_LIBRARY})
  set(CMAKE_C_CREATE_SHARED_MODULE ${CMAKE_CXX_CREATE_SHARED_MODULE})

  # create a C++ static library
 -set(CMAKE_CXX_CREATE_STATIC_LIBRARY  wlib ${CMAKE_LIB_QUIET} -c -n -b
 'TARGET_UNQUOTED'
 LINK_FLAGS OBJECTS )
 +set(CMAKE_CXX_CREATE_STATIC_LIBRARY  wlib ${CMAKE_LIB_QUIET} -c -n -b
 TARGET_QUOTED OBJECTS )

  # create a C static library
  set(CMAKE_C_CREATE_STATIC_LIBRARY ${CMAKE_CXX_CREATE_STATIC_LIBRARY})
 --
 1.8.0.msysgit.0

 Regards

 Jiri



 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Patch] Remove hard coded version of RTDLL for Open Watcom

[J Decker]

and a fix for 'option implib[=...]' as part of the wlink since it's a one
step anyway and not a dependant step


On Fri, Feb 28, 2014 at 6:47 PM, Jiri Malak malak.j...@gmail.com wrote:

 Hi,

 I enclosed next patch for Open Watcom toolchain, which remove hardcoded
 version number for RTDLL.
 It is derived from compiler version now that it will be working with OW
 version above 1.9.

 Regards

 Jiri


 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Watcom import library fails if no symbols in the DLL

[J Decker]

I was recently communicating with openwatcom matinainers; which just
released a version 2.0 fork on sourceforge... but the issue was
basically... if I have a shared library with no exports, it fails to build.

I used to use a method...(and this is how cmake does it)

wlink (...)  # build library
wlib (...) # build import library from wlink output

but doing it this way if the .dll has no exports, wlib results in an error,
and faults the build.

I was informed that the correct way is to build the import library during
the wlink step using 'option implib[=libname]'

I was able to successfully modify

./share/cmake-2.8/Modules/Platform/Windows-wcl386.cmake

** remove  at line 42

#set(CMAKE_C_CREATE_IMPORT_LIBRARY
#  wlib -c -q -n -b TARGET_IMPLIB +'TARGET_UNQUOTED')
#set(CMAKE_CXX_CREATE_IMPORT_LIBRARY ${CMAKE_C_CREATE_IMPORT_LIBRARY})
#

** modify line 69 (65 if 4 lines deleted)
 wlink ${CMAKE_START_TEMP_FILE} system nt_dll  ${CMAKE_WLINK_QUIET} name
'TARGET_UNQUOTED' LINK_FLAGS option caseexact  file {OBJECTS}
LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})

to include option implib=TARGET_IMPLIB

 wlink ${CMAKE_START_TEMP_FILE} system nt_dll  ${CMAKE_WLINK_QUIET} name
'TARGET_UNQUOTED' LINK_FLAGS option implib=TARGET_IMPLIB option
caseexact  file {OBJECTS} LINK_LIBRARIES ${CMAKE_END_TEMP_FILE})


and then the next line...

set(CMAKE_CXX_CREATE_SHARED_LIBRARY
  ${CMAKE_CXX_CREATE_SHARED_MODULE}
  ${CMAKE_CXX_CREATE_IMPORT_LIBRARY})

Includes a reference to the IMPORT_LIBRARY symbol removed before so that
can be removed.



Please update this for the future
-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Order of linking libraries

[J Decker]

It's in the same order as it is specified; if the same configuration
options are used, it should be the same list always.
IF things are somehow installed differently maybe; but the installed
libraries should still be located in the same order.

It is the same order for all generators.
The order of objects is always the order they are specified.

On Wed, Jan 22, 2014 at 2:31 AM, Marcin Maslany marcinmasl...@gmail.com wrote:
 Hello,

 what's the order of linking libraries? Is it always deterministic? I know it
 is possible to build dependency graph on libraries with cmake and find the
 correct order with topological sorting (this might be the way you do it).

 However, when I check the output from two builds (one after another) using
 cmake I can see that order is not always the same. I mean when I compare
 phrases Linking C/CXX static library ... Even if I run make with only one
 job.

 I totally agree that it still produces the correct binary, but I'd like to
 know if it's possible to ensure that the linking order of libraries is (no
 matter what machine I am running it on) deterministic? Of course, other than
 adding fake dependencies.

 I am just courius what is the reason of different order, even if I use the
 same machine to build binary.

 BR, Marcin Maslany

 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0014694]: Percent symbol (%) in path creates bad autogenerated paths

[J Decker]

work around; use #25; which is the xml code for % to escape it; It
needs to be encoded on the output to the visual studio XML
project/solution

On Mon, Jan 13, 2014 at 8:37 AM, Mantis Bug Tracker
man...@public.kitware.com wrote:

 The following issue has been SUBMITTED.
 ==
 http://www.cmake.org/Bug/view.php?id=14694
 ==
 Reported By:Geoff
 Assigned To:
 ==
 Project:CMake
 Issue ID:   14694
 Category:   CMake
 Reproducibility:always
 Severity:   minor
 Priority:   normal
 Status: new
 ==
 Date Submitted: 2014-01-13 11:37 EST
 Last Modified:  2014-01-13 11:37 EST
 ==
 Summary:Percent symbol (%) in path creates bad 
 autogenerated
 paths
 Description:
 When there is a percentage symbol (%) in the cmake file path, cmake creates 
 bad
 file paths to autogenerated .stamp and .sln files. The path to these files 
 seems
 to have concatenated a copy of itself. In visual studio 11, it reports these
 errors in the CUSTOMBUILD step for both the ZEROCHECK and user projects.

 Steps to Reproduce:
 1. Create a folder with a % in it
 2. Create a .c file with a simple main function
 3. Create a CMakeLists.txt file with an executable to a the .c file above
 4. Run cmake for Visual Studio 11
 5. Build all
 ==

 Issue History
 Date ModifiedUsername   FieldChange
 ==
 2014-01-13 11:37 Geoff  New Issue
 2014-01-13 11:37 Geoff  File Added: bugWithPercent%.zip

 ==

 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
-- 

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Cmake configure unicode?

[J Decker]

Should cmake be able to configure unicode, if the unicode file has
appropriate byte order indicators maybe?

I know it doesn't... for windows (and a bad test for if windows at that)

  macro( DO_CONFIGURE_FILE input output )
if( $ENV{COMSPEC} MATCHES cmd )
  STRING( REPLACE / \\ s1 ${CMAKE_CURRENT_SOURCE_DIR}/${input} )
  STRING( REPLACE / \\ s2 ${CMAKE_BINARY_DIR}/${output} )
  STRING( REPLACE / \\ finalout
${CMAKE_INSTALL_PREFIX}/${INTERFACE_OUTPUT_DIR}/${output} )
  STRING( REPLACE / \\ leader
${CMAKE_CURRENT_SOURCE_DIR}\\BlankUnicode.txt )
  EXECUTE_PROCESS(COMMAND cmd /c type ${s1} OUTPUT_FILE ${s2}.tmp )
  configure_file( ${s2}.tmp ${s2}.configured )
  EXECUTE_PROCESS(COMMAND cmd /U /C type ${s2}.configured
OUTPUT_FILE ${s2}.configured.unicode )
  EXECUTE_PROCESS(COMMAND cmd /c copy /b
${leader}+${s2}.configured.unicode ${finalout} )
else()
  message( NO METHOD TO CONFIGURE INTERFACE FILES )
  abort()
endif( $ENV{COMSPEC} MATCHES cmd )
  endmacro( DO_CONFIGURE_FILE )

Seems to work using a few temporary files and command prompt's copy
command to do the translation.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0014403]: Add an option to specify Visual Studio solution name

[J Decker]

the project name is the (last? first?) project( ${project_name} ) name.

On Thu, Sep 12, 2013 at 5:36 PM, Mantis Bug Tracker
man...@public.kitware.com wrote:

 The following issue has been SUBMITTED.
 ==
 http://www.cmake.org/Bug/view.php?id=14403
 ==
 Reported By:Cedric Perthuis
 Assigned To:
 ==
 Project:CMake
 Issue ID:   14403
 Category:   CMake
 Reproducibility:always
 Severity:   minor
 Priority:   normal
 Status: new
 ==
 Date Submitted: 2013-09-12 20:36 EDT
 Last Modified:  2013-09-12 20:36 EDT
 ==
 Summary:Add an option to specify Visual Studio solution 
 name
 Description:
 I haven't found how to specify the Visual Studio solution name. If it isn't
 supported, would it possible to add a variable for that?
 Maybe it applies for other IDEs as well.

 I saw a discussion about why it shouldn't be necessary and the last project 
 name
 should be picked, but somehow the solution name ends up being Project.
 Well for clarity when working with several solutions opened at the same time, 
 it
 would be nice to be able to define this.

 In the meantime, I'll create a wrapper which will change the visual studio 
 name
 after CMake runs, but it's not ideal.

 Thanks,
 Cedric
 ==

 Issue History
 Date ModifiedUsername   FieldChange
 ==
 2013-09-12 20:36 Cedric PerthuisNew Issue
 ==

 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Announcing CMake Tools for Visual Studio

[J Decker]

Yup; painless to install, works as described :)  Thanx

On Wed, May 15, 2013 at 4:37 PM, Klaim - Joël Lamotte mjkl...@gmail.com wrote:



 On Wed, May 15, 2013 at 1:04 AM, David Golub golu...@gmail.com wrote:

 I’m pleased to announce the first release candidate of CMake Tools for
 Visual Studio, an extension adding support for syntax highlighting and
 IntelliSense in CMake code using Microsoft Visual Studio.  The extension is
 open source (distributed under Ms-RL), freely available, and compatible with
 VS 2010 and VS 2012.  You can download it from the project from its web site
 on CodePlex at http://cmaketools.codeplex.com.  I hope that the extension
 will prove useful to the CMake community.  Please don’t hesitate to contact
 me if you’ve found any bugs that you’d like to report of it you’re
 interested in contributing to the project.  Enjoy!



 David Golub



 Hi,
 I've been looking for something like that by reflex for sometime, so I tried
 it right now (I have my CMakeLists.txt files visible in my VS projects).
 It seems to work well!
 Good work!

 I'll report if I find issues.

 Joel Lamotte


 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] project file conflict;An ah-hah moment

[J Decker]

for a while I've had an occasional issue something like

LINK : fatal error LNK1104: cannot open file
'C:\general\build\vs10-x86\sack\debug_solution\video_link\Debug\video_link
_server.ilk'
[C:\general\build\vs10-x86\sack\debug_solution\video_link\video_link_server.vcxproj]

I usually get these on systems with bad virus detection software that holds
files open too long.  This is a multiply-opened file.

I guess I can fix this by separating one of the projects into a
subdirectory which would change the name.

This is somewhat timing sensitive; and a second build always worked.  The
initial build did not always fail.

Basically what I have is...

 Begin CMakeLists.txt 

cmake_minimum_required(VERSION 2.8)

file( WRITE source.c void f( void ){ printf( \hello world\ ); }\n )
file( APPEND source.c void __stdcall WinMain( void*a,void*b,int c,int d ){
printf( \hello world\ ); } )

ADD_EXECUTABLE( video_link_server WIN32 source.c )

ADD_LIBRARY( video_link_server.isp SHARED source.c )

# commenting this out also makes it not happen; but should not affect the
incremental link file name...
SET_TARGET_PROPERTIES( video_link_server.isp PROPERTIES
   SUFFIX 
 )

 End 



Output

M:\tmp\cmake_crash\test5-overlapproject\buildcmake-gui ..
click configure, generate

M:\tmp\cmake_crash\test5-overlapproject\buildcmake --build .

Microsoft (R) Visual Studio Version 10.0.40219.1.
Copyright (C) Microsoft Corp. All rights reserved.
1-- Build started: Project: ZERO_CHECK, Configuration: Debug Win32
--
1  Checking Build System
1  CMake does not need to re-run because
M:/tmp/cmake_crash/test5-overlapproject/build/CMakeFiles/generate.stamp is
up-
to-date.
2-- Build started: Project: video_link_server, Configuration: Debug
Win32 --
3-- Build started: Project: video_link_server.isp, Configuration:
Debug Win32 --
2  Building Custom Rule
M:/tmp/cmake_crash/test5-overlapproject/cmakelists.txt
2  CMake does not need to re-run because
M:\tmp\cmake_crash\test5-overlapproject\build\CMakeFiles\generate.stamp is
up-
to-date.
2  source.c
2..\source.c(1): warning C4013: 'printf' undefined; assuming extern
returning int
3  Building Custom Rule
M:/tmp/cmake_crash/test5-overlapproject/cmakelists.txt
3  CMake does not need to re-run because
M:\tmp\cmake_crash\test5-overlapproject\build\CMakeFiles\generate.stamp is
up-
to-date.
3  source.c
3..\source.c(1): warning C4013: 'printf' undefined; assuming extern
returning int
*
*
*3LINK : fatal error LNK1104: cannot open file
'M:\tmp\cmake_crash\test5-overlapproject\build\Debug\video_link_server.il*k'


2  video_link_server.vcxproj -
M:\tmp\cmake_crash\test5-overlapproject\build\Debug\video_link_server.exe
4-- Build started: Project: ALL_BUILD, Configuration: Debug Win32
--
4  Building Custom Rule
M:/tmp/cmake_crash/test5-overlapproject/cmakelists.txt
4  CMake does not need to re-run because
M:\tmp\cmake_crash\test5-overlapproject\build\CMakeFiles\generate.stamp is
up-
to-date.
4  Build all projects
== Build: 3 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] project file conflict;An ah-hah moment

[J Decker]

On Fri, Apr 5, 2013 at 10:26 AM, Brad King brad.k...@kitware.com wrote:

 On 04/05/2013 12:50 PM, J Decker wrote:
  # commenting this out also makes it not happen; but should not affect
 the incremental link file name...
  SET_TARGET_PROPERTIES( video_link_server.isp PROPERTIES
 SUFFIX 
   )

 I can reproduce this in VS 2008, but there is nothing CMake can do.
 The generated project files do not include any information about
 the .ilk file; it is up to VS to construct that name.

 VS is taking the .isp suffix off and adding .ilk on because it
 expects to be stripping .exe or .dll.


Interesting; there isn't an option to override that... and /INCREMENTAL is
implied in /DEBUG so turning it off isn't an option either.  Oh well, it
works having put it in a subdirectory, so the outputs aren't in a similar
place.

the output names are video_link_server.exe and video_link_server.isp


 -Brad

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual studio usage

[J Decker]

I will probably complain from now until it's fixed with a perference
(which will probably mean me writing a patch; but... )

Devenv has a side effect that msbuild does not; devenv writes to the
most recently used projects, msbuild does not.   So I can keep using
visual studio to build my other c# projects that I work on, and even
have references to them in most recently used.

I have added to my toplevel cmakes a check for msbuild to set that
before the cmake default script checks; but this doesn't fix the
CMAKE_TRY_COMPILE.sln that's used by cmake itself; so running a series
of builds ends up basically obliterating the most recently used files
with CMAKE_TRY_COMPILE's.



On Fri, Jun 1, 2012 at 3:49 PM, J Decker d3c...@gmail.com wrote:
 shouldn't cmake use 'msbuild' instead of 'devenv.com' or 'devenv.exe'?

 I have a feeling that would solve one of my issues with visual studio,
 in that after building a long chain of cmake projects using visual
 studio, all of the most recent project references are updated to being
 the projects that were built, thereby losing the projects I'm actually
 working on.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process inconsitancy

[J Decker]

On Mon, Sep 3, 2012 at 7:50 PM, David Cole david.c...@kitware.com wrote:
 That's not a workaround, that's the solution. The quotes don't belong there.


I dunno seems to be an application specific failure



 On Sep 3, 2012, at 10:24 PM, J Decker d3c...@gmail.com wrote:

 I do have a workaround by taking the quotes out of the path...

 On Mon, Sep 3, 2012 at 7:23 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 3:58 PM, David Cole david.c...@kitware.com wrote:
 OK... Is hg.exe in the PATH? Do you get different results if you use
 the full path to hg.exe rather than just hg?

 hg is in the path; although, when hg is not in the path, the result is the 
 same.

 hg.exe is the same result


 PATH=C:\Windows;C:\Windows\system32;c:\develop\tools;c:\ftn3000\bin;c:\ftn3000\utility;;c:\Develop\tools\startups\..\..\tools\unix;c:\Develo
 p\tools\startups\..\..\tools\nasm;c:\Develop\tools\startups\..\..\tools\watcom\binnt;c:\Develop\tools\startups\..\..\tools\watcom\binw;c:\De
 velop\tools\startups\..\..\tools\unix\cmake\bin;C:\Program 
 Files\TortoiseHg\

 the following is the search...
 C:\Develop\tools\unix\cmake\bin\hg.exe
 cmake_source_dir
 32bit c:\windows\syswow64
 c:\windows\system.hg.exe
 c:\windows\hg.exe
 32bit c:\windows\syswow64
 c:\develop\tools
 c:\ftn3000\bin
 c:\ftn3000.. (path up to)

 c:\develop\tools\unix\cmake\bin\hg.exe

 then (and I think this is where it's wrong, I don't know how it would
 have created this path)

 M:\sack\c:\program files\tortoisehg\\hg.exe


 then it does the same search but looking for 'hg.exe id' instead of
 just 'hg.exe'






 On Mon, Sep 3, 2012 at 5:48 PM, J Decker d3c...@gmail.com wrote:
 dir c:\Program Files\tortoisehg
 Volume in drive C has no label.
 Volume Serial Number is F05B-C5AF

 Directory of c:\Program Files\tortoisehg
 
 08/20/2012  10:47 PM33,544 hg.exe
 

 I don't know what hy.py would be .

 On Mon, Sep 3, 2012 at 2:37 PM, David Cole david.c...@kitware.com wrote:
 On Mon, Sep 3, 2012 at 5:15 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 1:04 PM, Brad King brad.k...@kitware.com wrote:
 On 09/03/2012 03:04 PM, J Decker wrote:
 I use this command to get the current repository version number.

 Under windows I have to use 'cmd /c ...'
 under linux or I obviously can't use that.

 Is there a test I can do in a cmakelists to test the shell processor?

 Is there something I can do to make this the same command?

 Under windows, without cmd /c  the output variable is blank.


 if( WIN32 )

 execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

 else( WIN32 )

 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )


 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
 ERROR_VARIABLE TMP_CURRENT_REPO_REVISION2 )
 message( 1) ${TMP_CURRENT_REPO_REVISION} )
 message( 1) ${TMP_CURRENT_REPO_REVISION2} )

 both revision and revision2 are blank, (without cmd /c before)

 endif( WIN32 )

 The command operates the same way on both platforms.
 My guess is that hg is printing to stderr on Windows.
 Try this:

 execute_process(
   COMMAND hg id -i
   WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
   OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
   ERROR_VARIABLE TMP_CURRENT_REPO_REVISION
   )

 -Brad
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


 On Windows, hg is not an executable file, so execute_process is
 probably not even running it. If you instead say:

  COMMAND C:/python26/python.exe C:/path/to/hg.py (... args ...)

 does that work?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] execute_process inconsitancy

[J Decker]

I use this command to get the current repository version number.

Under windows I have to use 'cmd /c ...'
under linux or I obviously can't use that.

Is there a test I can do in a cmakelists to test the shell processor?

Is there something I can do to make this the same command?

Under windows, without cmd /c  the output variable is blank.


if( WIN32 )

execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

else( WIN32 )

execute_process( COMMAND hg id -i WORKING_DIRECTORY
${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

endif( WIN32 )
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process inconsitancy

[J Decker]

On Mon, Sep 3, 2012 at 1:04 PM, Brad King brad.k...@kitware.com wrote:
 On 09/03/2012 03:04 PM, J Decker wrote:
 I use this command to get the current repository version number.

 Under windows I have to use 'cmd /c ...'
 under linux or I obviously can't use that.

 Is there a test I can do in a cmakelists to test the shell processor?

 Is there something I can do to make this the same command?

 Under windows, without cmd /c  the output variable is blank.


 if( WIN32 )

 execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

 else( WIN32 )

 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )


execute_process( COMMAND hg id -i WORKING_DIRECTORY
${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
ERROR_VARIABLE TMP_CURRENT_REPO_REVISION2 )
message( 1) ${TMP_CURRENT_REPO_REVISION} )
message( 1) ${TMP_CURRENT_REPO_REVISION2} )

both revision and revision2 are blank, (without cmd /c before)

 endif( WIN32 )

 The command operates the same way on both platforms.
 My guess is that hg is printing to stderr on Windows.
 Try this:

  execute_process(
COMMAND hg id -i
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
ERROR_VARIABLE TMP_CURRENT_REPO_REVISION
)

 -Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process inconsitancy

[J Decker]

dir c:\Program Files\tortoisehg
 Volume in drive C has no label.
 Volume Serial Number is F05B-C5AF

 Directory of c:\Program Files\tortoisehg

08/20/2012  10:47 PM33,544 hg.exe


I don't know what hy.py would be .

On Mon, Sep 3, 2012 at 2:37 PM, David Cole david.c...@kitware.com wrote:
 On Mon, Sep 3, 2012 at 5:15 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 1:04 PM, Brad King brad.k...@kitware.com wrote:
 On 09/03/2012 03:04 PM, J Decker wrote:
 I use this command to get the current repository version number.

 Under windows I have to use 'cmd /c ...'
 under linux or I obviously can't use that.

 Is there a test I can do in a cmakelists to test the shell processor?

 Is there something I can do to make this the same command?

 Under windows, without cmd /c  the output variable is blank.


 if( WIN32 )

 execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

 else( WIN32 )

 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )


 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
 ERROR_VARIABLE TMP_CURRENT_REPO_REVISION2 )
 message( 1) ${TMP_CURRENT_REPO_REVISION} )
 message( 1) ${TMP_CURRENT_REPO_REVISION2} )

 both revision and revision2 are blank, (without cmd /c before)

 endif( WIN32 )

 The command operates the same way on both platforms.
 My guess is that hg is printing to stderr on Windows.
 Try this:

  execute_process(
COMMAND hg id -i
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
ERROR_VARIABLE TMP_CURRENT_REPO_REVISION
)

 -Brad
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


 On Windows, hg is not an executable file, so execute_process is
 probably not even running it. If you instead say:

   COMMAND C:/python26/python.exe C:/path/to/hg.py (... args ...)

 does that work?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process inconsitancy

[J Decker]

On Mon, Sep 3, 2012 at 3:58 PM, David Cole david.c...@kitware.com wrote:
 OK... Is hg.exe in the PATH? Do you get different results if you use
 the full path to hg.exe rather than just hg?

hg is in the path; although, when hg is not in the path, the result is the same.

hg.exe is the same result


PATH=C:\Windows;C:\Windows\system32;c:\develop\tools;c:\ftn3000\bin;c:\ftn3000\utility;;c:\Develop\tools\startups\..\..\tools\unix;c:\Develo
p\tools\startups\..\..\tools\nasm;c:\Develop\tools\startups\..\..\tools\watcom\binnt;c:\Develop\tools\startups\..\..\tools\watcom\binw;c:\De
velop\tools\startups\..\..\tools\unix\cmake\bin;C:\Program Files\TortoiseHg\

the following is the search...
C:\Develop\tools\unix\cmake\bin\hg.exe
cmake_source_dir
32bit c:\windows\syswow64
c:\windows\system.hg.exe
c:\windows\hg.exe
32bit c:\windows\syswow64
c:\develop\tools
c:\ftn3000\bin
c:\ftn3000.. (path up to)

c:\develop\tools\unix\cmake\bin\hg.exe

then (and I think this is where it's wrong, I don't know how it would
have created this path)

M:\sack\c:\program files\tortoisehg\\hg.exe


then it does the same search but looking for 'hg.exe id' instead of
just 'hg.exe'






 On Mon, Sep 3, 2012 at 5:48 PM, J Decker d3c...@gmail.com wrote:
 dir c:\Program Files\tortoisehg
  Volume in drive C has no label.
  Volume Serial Number is F05B-C5AF

  Directory of c:\Program Files\tortoisehg
 
 08/20/2012  10:47 PM33,544 hg.exe
 

 I don't know what hy.py would be .

 On Mon, Sep 3, 2012 at 2:37 PM, David Cole david.c...@kitware.com wrote:
 On Mon, Sep 3, 2012 at 5:15 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 1:04 PM, Brad King brad.k...@kitware.com wrote:
 On 09/03/2012 03:04 PM, J Decker wrote:
 I use this command to get the current repository version number.

 Under windows I have to use 'cmd /c ...'
 under linux or I obviously can't use that.

 Is there a test I can do in a cmakelists to test the shell processor?

 Is there something I can do to make this the same command?

 Under windows, without cmd /c  the output variable is blank.


 if( WIN32 )

 execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

 else( WIN32 )

 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )


 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
 ERROR_VARIABLE TMP_CURRENT_REPO_REVISION2 )
 message( 1) ${TMP_CURRENT_REPO_REVISION} )
 message( 1) ${TMP_CURRENT_REPO_REVISION2} )

 both revision and revision2 are blank, (without cmd /c before)

 endif( WIN32 )

 The command operates the same way on both platforms.
 My guess is that hg is printing to stderr on Windows.
 Try this:

  execute_process(
COMMAND hg id -i
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
ERROR_VARIABLE TMP_CURRENT_REPO_REVISION
)

 -Brad
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


 On Windows, hg is not an executable file, so execute_process is
 probably not even running it. If you instead say:

   COMMAND C:/python26/python.exe C:/path/to/hg.py (... args ...)

 does that work?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] execute_process inconsitancy

[J Decker]

I do have a workaround by taking the quotes out of the path...

On Mon, Sep 3, 2012 at 7:23 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 3:58 PM, David Cole david.c...@kitware.com wrote:
 OK... Is hg.exe in the PATH? Do you get different results if you use
 the full path to hg.exe rather than just hg?

 hg is in the path; although, when hg is not in the path, the result is the 
 same.

 hg.exe is the same result


 PATH=C:\Windows;C:\Windows\system32;c:\develop\tools;c:\ftn3000\bin;c:\ftn3000\utility;;c:\Develop\tools\startups\..\..\tools\unix;c:\Develo
 p\tools\startups\..\..\tools\nasm;c:\Develop\tools\startups\..\..\tools\watcom\binnt;c:\Develop\tools\startups\..\..\tools\watcom\binw;c:\De
 velop\tools\startups\..\..\tools\unix\cmake\bin;C:\Program Files\TortoiseHg\

 the following is the search...
 C:\Develop\tools\unix\cmake\bin\hg.exe
 cmake_source_dir
 32bit c:\windows\syswow64
 c:\windows\system.hg.exe
 c:\windows\hg.exe
 32bit c:\windows\syswow64
 c:\develop\tools
 c:\ftn3000\bin
 c:\ftn3000.. (path up to)

 c:\develop\tools\unix\cmake\bin\hg.exe

 then (and I think this is where it's wrong, I don't know how it would
 have created this path)

 M:\sack\c:\program files\tortoisehg\\hg.exe


 then it does the same search but looking for 'hg.exe id' instead of
 just 'hg.exe'






 On Mon, Sep 3, 2012 at 5:48 PM, J Decker d3c...@gmail.com wrote:
 dir c:\Program Files\tortoisehg
  Volume in drive C has no label.
  Volume Serial Number is F05B-C5AF

  Directory of c:\Program Files\tortoisehg
 
 08/20/2012  10:47 PM33,544 hg.exe
 

 I don't know what hy.py would be .

 On Mon, Sep 3, 2012 at 2:37 PM, David Cole david.c...@kitware.com wrote:
 On Mon, Sep 3, 2012 at 5:15 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Sep 3, 2012 at 1:04 PM, Brad King brad.k...@kitware.com wrote:
 On 09/03/2012 03:04 PM, J Decker wrote:
 I use this command to get the current repository version number.

 Under windows I have to use 'cmd /c ...'
 under linux or I obviously can't use that.

 Is there a test I can do in a cmakelists to test the shell processor?

 Is there something I can do to make this the same command?

 Under windows, without cmd /c  the output variable is blank.


 if( WIN32 )

 execute_process( COMMAND cmd /c hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )

 else( WIN32 )

 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION )


 execute_process( COMMAND hg id -i WORKING_DIRECTORY
 ${CMAKE_SOURCE_DIR} OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
 ERROR_VARIABLE TMP_CURRENT_REPO_REVISION2 )
 message( 1) ${TMP_CURRENT_REPO_REVISION} )
 message( 1) ${TMP_CURRENT_REPO_REVISION2} )

 both revision and revision2 are blank, (without cmd /c before)

 endif( WIN32 )

 The command operates the same way on both platforms.
 My guess is that hg is printing to stderr on Windows.
 Try this:

  execute_process(
COMMAND hg id -i
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
OUTPUT_VARIABLE TMP_CURRENT_REPO_REVISION
ERROR_VARIABLE TMP_CURRENT_REPO_REVISION
)

 -Brad
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


 On Windows, hg is not an executable file, so execute_process is
 probably not even running it. If you instead say:

   COMMAND C:/python26/python.exe C:/path/to/hg.py (... args ...)

 does that work?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] test for watcom version fails (InstallRequiredSYstemLibraries)

[J Decker]

Okay figured out the required mods to use the common version variable...

http://public.kitware.com/Bug/view.php?id=11866#c30208

On Fri, Aug 10, 2012 at 5:23 AM, Brad King brad.k...@kitware.com wrote:
 On 08/09/2012 09:00 PM, J Decker wrote:
 Please make mod to fix  (last message has correction)

 http://public.kitware.com/Bug/view.php?id=11866#bugnotes

 I don't have git available at this moment, but it's a one line change...

 See the note I just added here:

  http://www.cmake.org/Bug/view.php?id=11866#c30204

 -Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake and visual studio failing to build....

[J Decker]

Ya, unfortunatly I don't have the specific case that was failing
anymore... it's probably because I've been using the same build output
since 2.8.6 and just keep updating cmake... last couple versions have
actually gone smoothly


On Fri, Aug 10, 2012 at 4:21 AM, David Cole david.c...@kitware.com wrote:
 Can you try again with a nightly build of CMake?

 There's a change that we did not take that *is* in the nightly build,
 but is not in the 2.8.9 release. I'd like to know if that change is
 responsible for this behavior.

 We were uncertain of this commit [
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e16f58ddd6aea9bebc6b4a914eed54cf7517ff61
 ] ... so it did not go into the 2.8.9 release.


 Thx,
 David


 On Thu, Aug 9, 2012 at 7:33 PM, J Decker d3c...@gmail.com wrote:
 After considering this a bit more I went to this
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES  directory adn removed
 Build*.  and then everything built correctly.  And BuildX did not
 come back.  So maybe i've been changing cmake versions too much
 going to grab the 2.8.9 now anway.

 On Thu, Aug 9, 2012 at 4:27 PM, J Decker d3c...@gmail.com wrote:
 I'm having a little difficulty figuring out why this is not building
 my projects using visual studio/msbuild.  Basically all I get is
 == Build: 0 succeeded, 0 failed, 24 up-to-date, 0 skipped 
 ==

 I've used MSBuild with /v:diag set and in the huge log that that 
 generates

   Outputs for 
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\D460CDD940FC47A7C12689E8CBDF\BUILDCORE.RULE|M:\ALTANIK\CMAKE_ALL\CMAKELISTS.TXT:
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\GENERATE.STAMP 
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\BUILDCORE (TaskId:43)
   All outputs are up-to-date. (TaskId:43)

 How do I make sure that 'add_custom_target' is built?  and I shouldn't
 have to ask that because the docs say

 Adds a target with the given name that executes the given commands.
 The target has no output file and is ALWAYS CONSIDERED OUT OF DATE
 even if the commands try to create a file with the name of the
 target.




 macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT )
 #...
 add_custom_target( Build${PROJECT} ALL
 COMMAND cmake -G ${CMAKE_GENERATOR} ${PROJECT_SOURCE}
 -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
 -DCMAKE_INSTALL_PREFIX=${INSTALL} ${ARGN}
 COMMAND ${BUILD_COMMAND}
 WORKING_DIRECTORY ${BUILD}
 ${ADD_SOURCES}
 )
 #...
 endmacro()

 ADD_SOURCES is the .SLN filename
 BUILD is where it's building
 BUILD_COMMAND was retreived using build_command()

 and occasionally do ADD_CUSTOM_COMMAND( target Build${PROJECT}   ...
 some other commands... )


 on watcom, mingw, and usually visual studio, the cmake lists that uses
 this macro basically ends up running cmake and an approprite build
 command for each project...

 I have a bunch fo project build targets, and have added dependencies
 to most of that like  'add_dependencies( ${LAST_TARGET} Buildcore )'
 so Buildcore will get built first... last_target is set by the
 macro... yadda yadda.

 All of that works.

 But today, and some time last month a bit...
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake and visual studio failing to build....

[J Decker]

Mostly stable releases a week or so after non RC is released...

On Fri, Aug 10, 2012 at 11:39 AM, David Cole david.c...@kitware.com wrote:
 Have you even used a nightly CMake from the last month or so, or
 have you only been using release candidates and official releases?


 On Fri, Aug 10, 2012 at 2:35 PM, J Decker d3c...@gmail.com wrote:
 Ya, unfortunatly I don't have the specific case that was failing
 anymore... it's probably because I've been using the same build output
 since 2.8.6 and just keep updating cmake... last couple versions have
 actually gone smoothly


 On Fri, Aug 10, 2012 at 4:21 AM, David Cole david.c...@kitware.com wrote:
 Can you try again with a nightly build of CMake?

 There's a change that we did not take that *is* in the nightly build,
 but is not in the 2.8.9 release. I'd like to know if that change is
 responsible for this behavior.

 We were uncertain of this commit [
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e16f58ddd6aea9bebc6b4a914eed54cf7517ff61
 ] ... so it did not go into the 2.8.9 release.


 Thx,
 David


 On Thu, Aug 9, 2012 at 7:33 PM, J Decker d3c...@gmail.com wrote:
 After considering this a bit more I went to this
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES  directory adn removed
 Build*.  and then everything built correctly.  And BuildX did not
 come back.  So maybe i've been changing cmake versions too much
 going to grab the 2.8.9 now anway.

 On Thu, Aug 9, 2012 at 4:27 PM, J Decker d3c...@gmail.com wrote:
 I'm having a little difficulty figuring out why this is not building
 my projects using visual studio/msbuild.  Basically all I get is
 == Build: 0 succeeded, 0 failed, 24 up-to-date, 0 skipped 
 ==

 I've used MSBuild with /v:diag set and in the huge log that that 
 generates

   Outputs for 
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\D460CDD940FC47A7C12689E8CBDF\BUILDCORE.RULE|M:\ALTANIK\CMAKE_ALL\CMAKELISTS.TXT:
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\GENERATE.STAMP 
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\BUILDCORE (TaskId:43)
   All outputs are up-to-date. (TaskId:43)

 How do I make sure that 'add_custom_target' is built?  and I shouldn't
 have to ask that because the docs say

 Adds a target with the given name that executes the given commands.
 The target has no output file and is ALWAYS CONSIDERED OUT OF DATE
 even if the commands try to create a file with the name of the
 target.




 macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT )
 #...
 add_custom_target( Build${PROJECT} ALL
 COMMAND cmake -G ${CMAKE_GENERATOR} ${PROJECT_SOURCE}
 -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
 -DCMAKE_INSTALL_PREFIX=${INSTALL} ${ARGN}
 COMMAND ${BUILD_COMMAND}
 WORKING_DIRECTORY ${BUILD}
 ${ADD_SOURCES}
 )
 #...
 endmacro()

 ADD_SOURCES is the .SLN filename
 BUILD is where it's building
 BUILD_COMMAND was retreived using build_command()

 and occasionally do ADD_CUSTOM_COMMAND( target Build${PROJECT}   ...
 some other commands... )


 on watcom, mingw, and usually visual studio, the cmake lists that uses
 this macro basically ends up running cmake and an approprite build
 command for each project...

 I have a bunch fo project build targets, and have added dependencies
 to most of that like  'add_dependencies( ${LAST_TARGET} Buildcore )'
 so Buildcore will get built first... last_target is set by the
 macro... yadda yadda.

 All of that works.

 But today, and some time last month a bit...
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Cmake and visual studio failing to build....

[J Decker]

I'm having a little difficulty figuring out why this is not building
my projects using visual studio/msbuild.  Basically all I get is
== Build: 0 succeeded, 0 failed, 24 up-to-date, 0 skipped ==

I've used MSBuild with /v:diag set and in the huge log that that generates

  Outputs for 
C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\D460CDD940FC47A7C12689E8CBDF\BUILDCORE.RULE|M:\ALTANIK\CMAKE_ALL\CMAKELISTS.TXT:
(TaskId:43)
C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\GENERATE.STAMP (TaskId:43)
C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\BUILDCORE (TaskId:43)
  All outputs are up-to-date. (TaskId:43)

How do I make sure that 'add_custom_target' is built?  and I shouldn't
have to ask that because the docs say

Adds a target with the given name that executes the given commands.
The target has no output file and is ALWAYS CONSIDERED OUT OF DATE
even if the commands try to create a file with the name of the
target.




macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT )
#...
add_custom_target( Build${PROJECT} ALL
COMMAND cmake -G ${CMAKE_GENERATOR} ${PROJECT_SOURCE}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_INSTALL_PREFIX=${INSTALL} ${ARGN}
COMMAND ${BUILD_COMMAND}
WORKING_DIRECTORY ${BUILD}
${ADD_SOURCES}
)
#...
endmacro()

ADD_SOURCES is the .SLN filename
BUILD is where it's building
BUILD_COMMAND was retreived using build_command()

and occasionally do ADD_CUSTOM_COMMAND( target Build${PROJECT}   ...
some other commands... )


on watcom, mingw, and usually visual studio, the cmake lists that uses
this macro basically ends up running cmake and an approprite build
command for each project...

I have a bunch fo project build targets, and have added dependencies
to most of that like  'add_dependencies( ${LAST_TARGET} Buildcore )'
so Buildcore will get built first... last_target is set by the
macro... yadda yadda.

All of that works.

But today, and some time last month a bit...
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake and visual studio failing to build....

[J Decker]

After considering this a bit more I went to this
C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES  directory adn removed
Build*.  and then everything built correctly.  And BuildX did not
come back.  So maybe i've been changing cmake versions too much
going to grab the 2.8.9 now anway.

On Thu, Aug 9, 2012 at 4:27 PM, J Decker d3c...@gmail.com wrote:
 I'm having a little difficulty figuring out why this is not building
 my projects using visual studio/msbuild.  Basically all I get is
 == Build: 0 succeeded, 0 failed, 24 up-to-date, 0 skipped ==

 I've used MSBuild with /v:diag set and in the huge log that that generates

   Outputs for 
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\D460CDD940FC47A7C12689E8CBDF\BUILDCORE.RULE|M:\ALTANIK\CMAKE_ALL\CMAKELISTS.TXT:
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\GENERATE.STAMP 
 (TaskId:43)
 C:\GENERAL\BUILD\VS10-X86\ALTANIK\CMAKEFILES\BUILDCORE (TaskId:43)
   All outputs are up-to-date. (TaskId:43)

 How do I make sure that 'add_custom_target' is built?  and I shouldn't
 have to ask that because the docs say

 Adds a target with the given name that executes the given commands.
 The target has no output file and is ALWAYS CONSIDERED OUT OF DATE
 even if the commands try to create a file with the name of the
 target.




 macro( BuildProject PROJECT SOLUTION PROJECT_SOURCE INSTALL_RESULT )
 #...
 add_custom_target( Build${PROJECT} ALL
 COMMAND cmake -G ${CMAKE_GENERATOR} ${PROJECT_SOURCE}
 -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
 -DCMAKE_INSTALL_PREFIX=${INSTALL} ${ARGN}
 COMMAND ${BUILD_COMMAND}
 WORKING_DIRECTORY ${BUILD}
 ${ADD_SOURCES}
 )
 #...
 endmacro()

 ADD_SOURCES is the .SLN filename
 BUILD is where it's building
 BUILD_COMMAND was retreived using build_command()

 and occasionally do ADD_CUSTOM_COMMAND( target Build${PROJECT}   ...
 some other commands... )


 on watcom, mingw, and usually visual studio, the cmake lists that uses
 this macro basically ends up running cmake and an approprite build
 command for each project...

 I have a bunch fo project build targets, and have added dependencies
 to most of that like  'add_dependencies( ${LAST_TARGET} Buildcore )'
 so Buildcore will get built first... last_target is set by the
 macro... yadda yadda.

 All of that works.

 But today, and some time last month a bit...
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] test for watcom version fails (InstallRequiredSYstemLibraries)

[J Decker]

Please make mod to fix  (last message has correction)

http://public.kitware.com/Bug/view.php?id=11866#bugnotes

I don't have git available at this moment, but it's a one line change...
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] flags if target is add_executable( WIN32 )

[J Decker]

There's no way to set additional flags to compile if the
add_exectuable is WIN32 or console?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] GCC link options

[J Decker]

Is there a super simple way to get the current build command for say
exectuable, string(replace) it, and then execute it in a custom
target?

On Wed, Jul 25, 2012 at 11:31 AM, Brad King brad.k...@kitware.com wrote:
 On 07/25/2012 02:12 PM, J Decker wrote:
 target_link_libraries(  playcard --whole-archive
 eltanin_sdl_deadstart_end --no-whole-archive ${COMMON_LIBRARIES} )
 (the output link line looks like .  libplaycard.a --whole-archive
 eltanin_sdl_deadstart_end.a libcommon.a --no-whole-archive )

 The only ordering guarantee is that the target being linked
 (final executable or shared library) has its own sequence
 first as specified by target_link_libraries.  Transitive
 dependencies of the libraries named at the first level will
 all appear in order but may have other things inserted.

that is the behavior I observe, but, I don't understand why a library
would be inserted in the middle of a set of libraries...



 The only reliable place to put flags is in the top-level call
 to target_link_libraries for the target getting linked.  For
 example:

  add_executable(foo foo.c)
  target_link_libraries(foo ${libs}
--whole-archive ${special} --no-whole-archive)

 will result in

  -o foo ${libs} --whole-archive ${special} --no-whole-archive ${depends}


which goes back to remove all implied dependencies and make one big list.


 Alternatively, using CMake 2.8.8 you can also use an object library:

  add_library(eltanin_sdl_deadstart_end OBJECT src.c)
  add_executable(foo foo.c $TARGET_OBJECTS:eltanin_sdl_deadstart_end)
  target_link_libraries(foo ${libs})

 That will ensure the desired objects end up in the executable.
 They will be listed explicitly on the link line as .o files.


Ya, but some of the items added to the deadstart section are in .a
files, so it has to be after all of those also

Migrating to shared libraries can also solve this; but, turns out they
used circular references in the libraries

None of this is good news :(

Thanx though.

 -Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] GCC link options

[J Decker]

Okay I think maybe it's that the marker for the end of the list is not
in the right spot.
All my other projects I have been building as shared libraries, but
this one is based on static libs.

I need to specify at the end of all libraries a seperate library
but after all the libraries that have been applied to this exectuable
target are a bunch more libraries, presumably the ones that are
recursively referenced by other libs

So how can I add a library to the very end of the list to link?

On Mon, Jul 23, 2012 at 5:35 PM, J Decker d3c...@gmail.com wrote:
 On Mon, Jul 23, 2012 at 2:45 PM, Brad King brad.k...@kitware.com wrote:
 On 07/23/2012 02:31 PM, J Decker wrote:
 In this commit --no-whole-archive is artificially added to compile
 options in Modules/Platform/Windows-GNU.cmake.

 http://cmake.org/gitweb?p=cmake.git;a=commit;h=5f05a3c25e1480648f46c9ccbf775225f9e8e32d

 This is causes no end of problems for me; because I have code which is
 indirectly referenced such that LD doesn't identify it as being used.

 By what mechanism is code indirectly referenced such that
 references are not visible to the linker?


 I'm not entirely sure...  these are the defines/relavent data structures...

 even though I apply  __attribute__((used)), though it's in another
 section __attribute__((section(deadstart_list))) ...

 so the static routine and the static structure should be kept; part of
 the init of the structure is the address of the routine to make sure
 that's kept... but the only references are between the data and the
 code... but somehow these blocks of code and data are being omitted
 when linking from .a files.

 I link a object at the start and end that contain the beginning and
 end of 'deadstart_list' section, which I go through and use all the
 structures that have been compiled there.  It's a way to schedule
 pre-runtime code initializers... (things that run before main)

 typedef unsigned char   __type_rtp;
 typedef void(*__type_rtn ) ( void );
 struct rt_init // structure placed in XI/YI segment
 {
 #ifdef __cplusplus
 //rt_init( int _rtn_type ) { rt_init::rtn_type = _rtn_type; }
 /*rt_init( int _priority, CTEXTSTR name, __type_rtn rtn, CTEXTSTR
 _file, int _line )
 {
 rtn_type = 0;
 scheduled = 0;
 priority = priority;
 file = _file;
 line = _line;
   routine = rtn;
 }
   */
 #endif
 #define DEADSTART_RT_LIST_START 0xFF
 __type_rtp  rtn_type; // - near=0/far=1 routine indication
   //   also used when walking table to flag
   //   completed entries
 __type_rtp  scheduled; // has this been scheduled? (0 if no)
 __type_rtp  priority; // - priority (0-highest 255-lowest)
 #define INIT_PADDING ,{0}
  char padding[1]; // need this otherwise it's 23 bytes and that'll be 
 bad.
  int line; // 32 bits in 64 bits
  __type_rtn  routine;  // - routine (rtn)
  CTEXTSTR file;
  CTEXTSTR funcname;
  struct rt_init *junk;
 .struct rt_init *junk2[3];
 . __attribute__((packed));

 #define JUNKINIT(name) ,pastejunk(name,_ctor_label)
 #define RTINIT_STATIC static

 #define PRIORITY_PRELOAD(name,pr) static void name(void); \
 RTINIT_STATIC struct rt_init pastejunk(name,_ctor_label) \
   __attribute__((section(deadstart_list))) __attribute__((used)) \
 ={0,0,pr INIT_PADDING\
  ,__LINE__,name \
  ,WIDE__FILE__\
 ,#name\
 JUNKINIT(name)}; \
 static void name(void) __attribute__((used));  \
 void name(void)



 Depending on your use case consider the object library feature:

  http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library

 any idea how I can get around the --no-whole-archive flag?

 target_link_libraries(my_target -Wl,--whole-archive my_archive)

 I'll try adding that as the first library...


 -Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] GCC link options

[J Decker]

In this commit --no-whole-archive is artificially added to compile
options in Modules/Platform/Windows-GNU.cmake.

http://cmake.org/gitweb?p=cmake.git;a=commit;h=5f05a3c25e1480648f46c9ccbf775225f9e8e32d

This is causes no end of problems for me; because I have code which is
indirectly referenced such that LD doesn't identify it as being used.

I don't know what the proper thing is...


CMAKE_${lang}_COMPILER FLAGS CMAKE_${lang}_LINK_FLAGS
LINK_FLAGS OBJECTS  -o TARGET -Wl,--out-implib,TARGET_IMPLIB
${CMAKE_GNULD_IMAGE_VERSION} ${LD_FLAGS} LINK_LIBRARIES)

in the above I've inserted ${LD_FLAGS} which lets me put the
--whole-archive mode back in but actually no, it doesn't I
geuss I can't set those flags soon enough

any idea how I can get around the --no-whole-archive flag?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] new Generator

[J Decker]

On Mon, Jul 2, 2012 at 7:57 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
 On 7/2/2012 10:25 AM, J Decker wrote:

 lcc
 lcc-win32/64


 Using nmake,jom, gmake or ninja that should not require a new generator.
 Just a few platform files.  See Modules/Platform:



ninja looks promising as an inbetween; lcc of course has it's own
make.  I however don't find ninja on windows latest download...
there's a couple references in the /share/

 altneratively some other flavors of visual studio projects

 These would most likely be sub-classes of the existing generators.  What
 flavors where you thinking of?  (chocolate, vanilla?) :)


a flag to enable generating a line when compiling CLR which allows
adding references to .NET things to the project.  (soemthing that has
to be manually set for each target)

something like CLRSupportrue/CLRSupport

http://www.mail-archive.com/cmake@cmake.org/msg39818.html

 Might also be just a flag or two set on existing generators.


 -Bill

 --
 Bill Hoffman
 Kitware, Inc.
 28 Corporate Drive
 Clifton Park, NY 12065
 bill.hoff...@kitware.com
 http://www.kitware.com
 518 881-4905 (Direct)
 518 371-3971 x105
 Fax (518) 371-4573


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] new Generator

[J Decker]

On Mon, Jul 2, 2012 at 6:55 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
 On 6/21/2012 12:10 PM, J Decker wrote:

 Is tehre anywhere that I can find a howto of how to approach creating
 a new genreator?
 --


 What generator are you planning to write?


lcc
lcc-win32/64

altneratively some other flavors of visual studio projects

 -Bill
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] help finding where file installs from

[J Decker]

I have a file that gets installed with a bunch of other files.  Only
the file in question is getting installed a couple times.  I know
where the one is coming from, but I cannot find where the other is.
I've updated to using general things like INSTALL( DIRECTORY ... ) so
there's no references to the file directly except in the
install.manifest file.  How can I find where it's getting a second
copy from?  There's only one copy in the source tree, there's only one
copy up to the point this project builds in the build tree... this
project should be using the one in the build tree, from a prior
project that has been built, and should be the only one.  Heck, I
don't even know where it could be finding this file that is a
different timestamp on the system.

mingw, make VERBOSE=1 doesn't help, watcom and visual studio both have
no sign of the file in question in build 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] help finding where file installs from

[J Decker]

Sorry nevermind, there was a file added in the sources.

On Wed, Jun 27, 2012 at 9:20 AM, J Decker d3c...@gmail.com wrote:
 I have a file that gets installed with a bunch of other files.  Only
 the file in question is getting installed a couple times.  I know
 where the one is coming from, but I cannot find where the other is.
 I've updated to using general things like INSTALL( DIRECTORY ... ) so
 there's no references to the file directly except in the
 install.manifest file.  How can I find where it's getting a second
 copy from?  There's only one copy in the source tree, there's only one
 copy up to the point this project builds in the build tree... this
 project should be using the one in the build tree, from a prior
 project that has been built, and should be the only one.  Heck, I
 don't even know where it could be finding this file that is a
 different timestamp on the system.

 mingw, make VERBOSE=1 doesn't help, watcom and visual studio both have
 no sign of the file in question in build 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Visual studio CLR Support

[J Decker]

In the property group for 'configuration' there is a field
CLRSupporttrue/CLRSupport which is set and exists if CLR support
is enabled.  I have set the flags on all of the projects; but I don't
know if there's a way to turn this one, and this controls how the
project reacts, for instance when adding references, without this
flag, you can only select other projects as dependencies, whereas when
it's enabled, you can add .NET references for things like 'System'.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] new Generator

[J Decker]

On Mon, Jun 25, 2012 at 12:34 PM, Alexander Neundorf neund...@kde.org wrote:
 Hi,

 On Thursday 21 June 2012, J Decker wrote:

 Is tehre anywhere that I can find a howto of how to approach creating

 a new genreator?

 basically, read the sources.

 For what IDE or build tool would you like to write one ?

lcc
lcc-win32/64

altneratively some other flavors of visual studio projects


 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] new Generator

[J Decker]

Is tehre anywhere that I can find a howto of how to approach creating
a new genreator?
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Visual Studio Add Custom Target marked Build

[J Decker]

On Wed, Jun 13, 2012 at 9:09 AM, David Cole david.c...@kitware.com wrote:
 You can get install_foo to build always if you include ALL as an arg to
 add_custom_target.

 You cannot use INSTALL in an add_dependencies call, though. Rather, you
 could list the executables that you need built *before* an install could be
 successful -- that should be equivalent, but requires you to list them
 explicitly. See http://public.kitware.com/Bug/view.php?id=8438 for more
 details.

Hmm, but what I'm really trying to accomplish is to build INSTALL...
listing the things to build before the install will end up just
building those... and ya, so adding ALL made it a circular dependency
list that won't work unless it's a static library(according to vs2010)

if I could have the install target marked to be built that would be
just as fine.


 HTH,
 David


 On Wed, Jun 13, 2012 at 12:02 PM, J Decker d3c...@gmail.com wrote:

 how to add a custom target which is marked as build in a visual studio
 solution output?

 I really am trying to get away from devenv, when using devenv, it will
 build the INSTALL target even though it's not marked for build.  But
 MSBuild isn't so gracious so I added

  ADD_CUSTOM_TARGET( install_foo )
  ADD_DEPENDENCIES( install_foo INSTALL )

 but target 'install_foo' also isn't marked to be built.
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Visual Studio Add Custom Target marked Build

[J Decker]

Oh, I can have it build INSTALL.vcxproj instead of my_project.sln with
target INSTALL.

On Wed, Jun 13, 2012 at 9:17 AM, J Decker d3c...@gmail.com wrote:
 On Wed, Jun 13, 2012 at 9:09 AM, David Cole david.c...@kitware.com wrote:
 You can get install_foo to build always if you include ALL as an arg to
 add_custom_target.

 You cannot use INSTALL in an add_dependencies call, though. Rather, you
 could list the executables that you need built *before* an install could be
 successful -- that should be equivalent, but requires you to list them
 explicitly. See http://public.kitware.com/Bug/view.php?id=8438 for more
 details.

 Hmm, but what I'm really trying to accomplish is to build INSTALL...
 listing the things to build before the install will end up just
 building those... and ya, so adding ALL made it a circular dependency
 list that won't work unless it's a static library(according to vs2010)

 if I could have the install target marked to be built that would be
 just as fine.


 HTH,
 David


 On Wed, Jun 13, 2012 at 12:02 PM, J Decker d3c...@gmail.com wrote:

 how to add a custom target which is marked as build in a visual studio
 solution output?

 I really am trying to get away from devenv, when using devenv, it will
 build the INSTALL target even though it's not marked for build.  But
 MSBuild isn't so gracious so I added

  ADD_CUSTOM_TARGET( install_foo )
  ADD_DEPENDENCIES( install_foo INSTALL )

 but target 'install_foo' also isn't marked to be built.
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual studio usage

[J Decker]

There are two reasons this is an issue (for me)

1) using devenv to build is MUCH slower on many of the projects than
just using MSBuild.  ... yes I know, longer build times mean more time
at the water cooler or whatever...

2) Using devenv, each project that gets built becomes a
most-recently-used file for visual studio, so the things I'm actually
working on (not the dozens of projects that get built with automated
method) get lost; they get shoved off the list of recently used files
pretty quick.

On Thu, Jun 7, 2012 at 9:22 AM, J Decker d3c...@gmail.com wrote:
 Okay I saw the comments in the platform scripts about fortran, but
 maybe a symbol could be added to maybe prefer msbuild; there are a
 couple like that for InstallSystemRuntimeLibraries or whatever that
 was... so you can control the behavior.  The other alternative might
 be add additional options for generators that prefer one or the other.

 if( PREFER_MSBUILD )

 On Sat, Jun 2, 2012 at 2:17 PM, Pau Garcia i Quiles
 pgqui...@elpauer.org wrote:
 Hi,

 It will probably introduce other problems:

 MsBuild woes
 http://www.elpauer.org/?p=955


 On Sat, Jun 2, 2012 at 12:49 AM, J Decker d3c...@gmail.com wrote:
 shouldn't cmake use 'msbuild' instead of 'devenv.com' or 'devenv.exe'?

 I have a feeling that would solve one of my issues with visual studio,
 in that after building a long chain of cmake projects using visual
 studio, all of the most recent project references are updated to being
 the projects that were built, thereby losing the projects I'm actually
 working on.

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual studio usage

[J Decker]

I mean using cmake --build . and/or getting BUILD_COMMAND from cmake
which comes back as devenv which is then used to build projects.

I had a bunch of cmake projects that built from a batch file, then I
made a cmakelists that does the same thing, so I have one
cmakelists.txt which builds all other top level cmakelists.

On Fri, Jun 8, 2012 at 9:11 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
 Hi,

 Sorry but it's not clear to me: when you say using devenv do you
 mean opening the IDE, or do you mean calling devenv form the
 command-line like devenv /build Debug mysolution.sln? The former is
 slow due to IntelliSense, ReSharper, etc but the latter is very fast.


 On Fri, Jun 8, 2012 at 5:59 PM, J Decker d3c...@gmail.com wrote:
 There are two reasons this is an issue (for me)

 1) using devenv to build is MUCH slower on many of the projects than
 just using MSBuild.  ... yes I know, longer build times mean more time
 at the water cooler or whatever...

 2) Using devenv, each project that gets built becomes a
 most-recently-used file for visual studio, so the things I'm actually
 working on (not the dozens of projects that get built with automated
 method) get lost; they get shoved off the list of recently used files
 pretty quick.

 On Thu, Jun 7, 2012 at 9:22 AM, J Decker d3c...@gmail.com wrote:
 Okay I saw the comments in the platform scripts about fortran, but
 maybe a symbol could be added to maybe prefer msbuild; there are a
 couple like that for InstallSystemRuntimeLibraries or whatever that
 was... so you can control the behavior.  The other alternative might
 be add additional options for generators that prefer one or the other.

 if( PREFER_MSBUILD )

 On Sat, Jun 2, 2012 at 2:17 PM, Pau Garcia i Quiles
 pgqui...@elpauer.org wrote:
 Hi,

 It will probably introduce other problems:

 MsBuild woes
 http://www.elpauer.org/?p=955


 On Sat, Jun 2, 2012 at 12:49 AM, J Decker d3c...@gmail.com wrote:
 shouldn't cmake use 'msbuild' instead of 'devenv.com' or 'devenv.exe'?

 I have a feeling that would solve one of my issues with visual studio,
 in that after building a long chain of cmake projects using visual
 studio, all of the most recent project references are updated to being
 the projects that were built, thereby losing the projects I'm actually
 working on.

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual studio usage

[J Decker]

I woudl rather have it discover it for the appropriate version of
visual studio I select as a generator, I have already copied the
findprogram code from the script and put it at the head of a couple of
the scripts, but this doesn't fix that the outer layer is still being
built with devenv.  I don't really want to build a find_program
function for batch files

On Fri, Jun 8, 2012 at 9:37 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
 On Fri, Jun 8, 2012 at 6:26 PM, Óscar Fuentes o...@wanadoo.es wrote:
 J Decker d3c...@gmail.com writes:

 I mean using cmake --build . and/or getting BUILD_COMMAND from cmake
 which comes back as devenv which is then used to build projects.

 I had a bunch of cmake projects that built from a batch file, then I
 made a cmakelists that does the same thing, so I have one
 cmakelists.txt which builds all other top level cmakelists.

 cmake -DCMAKE_MAKE_PROGRAM=msbuild .

 ?

 Sometimes that will fail due to the different way msbuild and devenv
 compute project dependencies.

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)
 --

 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] visual studio usage

[J Decker]

Okay I saw the comments in the platform scripts about fortran, but
maybe a symbol could be added to maybe prefer msbuild; there are a
couple like that for InstallSystemRuntimeLibraries or whatever that
was... so you can control the behavior.  The other alternative might
be add additional options for generators that prefer one or the other.

if( PREFER_MSBUILD )

On Sat, Jun 2, 2012 at 2:17 PM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
 Hi,

 It will probably introduce other problems:

 MsBuild woes
 http://www.elpauer.org/?p=955


 On Sat, Jun 2, 2012 at 12:49 AM, J Decker d3c...@gmail.com wrote:
 shouldn't cmake use 'msbuild' instead of 'devenv.com' or 'devenv.exe'?

 I have a feeling that would solve one of my issues with visual studio,
 in that after building a long chain of cmake projects using visual
 studio, all of the most recent project references are updated to being
 the projects that were built, thereby losing the projects I'm actually
 working on.

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] visual studio usage

[J Decker]

shouldn't cmake use 'msbuild' instead of 'devenv.com' or 'devenv.exe'?

I have a feeling that would solve one of my issues with visual studio,
in that after building a long chain of cmake projects using visual
studio, all of the most recent project references are updated to being
the projects that were built, thereby losing the projects I'm actually
working on.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 2.8.6-rc1 ready for testing!

[J Decker]

Thought this came out weeks ago... and I would miss a chance to comment.

Watcom support is almost working, the new test version code is...

  EXECUTE_PROCESS(COMMAND ${CMAKE_TEST_COMPILER}
-q -pc \${testWatcomVersionFile}\
OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT
RESULT_VARIABLE CMAKE_COMPILER_RETURN
)

which looks OK. But if I change it to
  EXECUTE_PROCESS(COMMAND echo ${CMAKE_TEST_COMPILER}
-q -pc \${testWatcomVersionFile}\
OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT
RESULT_VARIABLE CMAKE_COMPILER_RETURN
)


then the command looks like

e:/tools/watcom/binnt/wcl386.exe -q -pc
\e:\tools\unix\cmake\share\cmake-2.8\Modules\CMakeTestWatcomVersion.c


(as is set in CMAKE_COMPILER_OUTPUT) but anyhow...

I don't know where the extra \ before the e:\ is coming from.

message( ${testWatcomVersionFile} )
is
e:\tools\unix\cmake\share\cmake-2.8\Modules\CMakeTestWatcomVersion.c

right before the execute command.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] I'm sure this is often asked

[J Decker]

Any reason that environment variables can't be used as cmake
variables?  Like of course any cmake variable in a script would
override the environment, but if it's not otherwise found, checking in
the environemnt would make scripts prettier.


set BUILD_TYPE=debug
set BUILD_MONOLITHIC=1
cmake /path/to/source

instead of having to pass -DBUILD_TYPE=debug -DBUILD_MONOLITHIC which
gets strung out all on one line usually.  some longer varaibles might
be -DSACK_INTERSHELL_SDK_ROOT_PATH=$SACK_INTERSHELL_SDK_ROOT_PATH

or appropriate bash/batch syntax as applicable.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW

[J Decker]

On Wed, Jun 22, 2011 at 9:06 PM, Clinton Stimpson clin...@elemtech.com wrote:

 On Jun 22, 2011, at 9:11 PM, Alan W. Irwin wrote:

 On 2011-06-22 17:36-0400 Mantis Bug Tracker wrote:


 The following issue has been SUBMITTED.
 ==
 http://public.kitware.com/Bug/view.php?id=12301
 ==
 Reported By:                Stephen Kelly
 Assigned To:
 ==
 Project:                    CMake
 Issue ID:                   12301
 Category:                   CMake
 Reproducibility:            always
 Severity:                   minor
 Priority:                   normal
 Status:                     new
 ==
 Date Submitted:             2011-06-22 17:36 EDT
 Last Modified:              2011-06-22 17:36 EDT
 ==
 Summary:                    CMAKE_BUILD_TYPE not set on MinGW
 Description:

 CMAKE_BUILD_TYPE is not set when using MinGW, which causes problems with 
 loading
 Qt plugins unless the user manually sets the CMAKE_BUILD_TYPE.

 CMAKE_BUILD_TYPE should be preset to debug or release, as it is on most 
 other
 platforms.

 Context here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36994/focus=37032

 I have an interest is this bug report and the above thread because of
 my MinGW/wine tests and experiments with the Qt4 components of PLplot.
 Also, we currently have a user who is having a devil of a time getting
 the Qt4 components of PLplot to work reliably on Windows.

 I have read that thread, but would some MinGW/Windows expert here
 (such as, ahem, Clint) explain what the real issue is?

 On Linux, CMAKE_BUILD_TYPE is also not set, but the Qt4 aspects of our
 PLplot build work fine there.  In other words, the Unix Makefiles
 generator and associated CMake Linux gcc compiler support know exactly
 what to do if the CMAKE_BUILD_TYPE is not set.  (I assume from the
 documentation that means that the release version of Qt4 is chosen
 rather than the debug version, but I haven't verified that.) So is the
 issue really that either/both of MinGW Makefiles or MSYS Makefiles
 combined with the CMake Windows MinGW compiler support don't know how
 to correctly handle the case where CMAKE_BUILD_TYPE is not set?

 Currently, I must say I have sometimes had success with the Qt4
 components of PLplot on wine and sometimes not, and I haven't yet
 pinned down the reason.  And we have a PLplot user with very similar
 Qt4/PLplot reliability issues using MinGW on the Microsoft version of
 Windows.  Because of the information in the above bug report I will
 try manually setting CMAKE_BUILD_TYPE (I haven't done that before) the
 next time I build and test PLplot on wine, and I have suggested our
 user do the same on Microsoft Windows, in the hope it will make the
 Qt4 components of PLplot more reliable on those platforms.

 Clint, I had planned to restart MinGW/MSYS/Wine and MinGW/Wine testing
 of PLplot builds in the next several weeks, but I could start those
 tests earlier if it would clarify some of the issues you discovered for the
 case when CMAKE_BUILD_TYPE was not set manually.

 This issue is with how Qt plugins are compiled.  It has come up a couple 
 times in the past, but this might be the first with MinGW.

 When Qt is configured, a build key is generated that is configuration 
 specific (see qconfig.h).
 On Windows, the build key for the debug and release libs are different 
 (regardless of the compiler used  -- although they may only need to really do 
 it for MSVC because only it has separate debug and release runtimes).

 When a user creates a Qt plugin, that build key gets embedded into the plugin 
 (see build key used in qplugin.h), so it can only be loaded with a compatible 
 Qt build.
 On Windows, the correct debug or release build key needs to be used, and 
 choosing the correct one is dependent on compiling with -DQT_NO_DEBUG or 
 -DQT_DEBUG.  If neither is defined, qglobal.h automatically sets QT_DEBUG, 
 which means it is assuming a debug build, even if one links against the 
 release Qt libs.  I wonder if there is a way to patch Qt to make a better 
 assumption.

 So anyway, Stephen was having this issue because the build type was not 
 explicit and Qt assumed debug and CMake assumed Release (by choosing to link 
 with the release Qt libs), and the plugin was compiled with the wrong build 
 key, so it wouldn't load at runtime.  CMake sets a build type by default for 
 MSVC compilers, but not MinGW or MSYS.  The bug report requests that a 
 default build type be specified instead of left empty.


Think some cmake script should be modified to specify the default
build types as a drop list for the gui with a default of what cmake
would be (I guess release); there's