Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

2014-10-22 Thread Sean McBride
On Wed, 22 Oct 2014 19:29:00 +0200, Adam Strzelecki said:

>> The nightly binary works again.  The first working version after
>> this gap is now:
>
>Great! Now, do you plan code signing the CMake.app? Do you guys have Mac
>Developer ID?

The bug for that is here BTW, created over 2 years ago now...


Cheers,

-- 

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


-- 

Powered by www.kitware.com

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] fix-OSX-bundle-rpaths-and-Qt5 topic

2014-10-22 Thread Adam Strzelecki
> The nightly binary works again.  The first working version after
> this gap is now:

Great! Now, do you plan code signing the CMake.app? Do you guys have Mac 
Developer ID?

--Adam
-- 

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] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments

2014-10-22 Thread Brad King
On 10/21/2014 10:01 AM, Daniele E. Domenichelli wrote:
> I would like to be able to set some some variables (for example
> CMAKE_BUILD_TYPE) for all the "external project" according to the value
> in the "super-project", but the same time I would like to be able to
> change them (for example change CMAKE_BUILD_TYPE to Debug if I'm
> building in Release mode) for just one external project without changing
> it in all of them, and having to rebuild everything.

How about a new option like "CMAKE_CACHE_DEFAULT_ARGS" for that?

-Brad

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

2014-10-22 Thread Brad King
On 10/21/2014 11:45 AM, Brad King wrote:
> I cherry-picked it over on top of the revised/squashed copy of
> the topic that was merged to 'master':
> 
>  BundleUtilities: Ensure framework symlinks and Info.plist exist
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2

The nightly binary works again.  The first working version after
this gap is now:

 http://www.cmake.org/files/dev/cmake-3.1.20141021-gffa1-Darwin64-universal.dmg

Thanks!
-Brad

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake.app Qt5 vs Qt4 on 10.10

2014-10-22 Thread Brad King
On 10/21/2014 12:16 PM, Adam Strzelecki wrote:
> Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic
> I just wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite:
> 
>   
> https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png
>   https://www.dropbox.com/s/tm95rntexn4z6j6/CMake3.1rc1-Qt5.4-Yosemite.png

Cool, thanks for testing both versions.  We'd like to switch to Qt5
when we get a chance to update our binary build infrastructure for it.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] Chaining custom commands in VS 2010

2014-10-22 Thread Brad King
On 10/21/2014 05:09 PM, James Bigler wrote:
> I never did actually submit this bug.  Do you know if this is a problem for 
> VS 2013?  

Yes, I just tried the case I previously posted:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/44820/focus=6288

and the results are identical even after adding

  v120

to the project file.

-Brad

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE

2014-10-22 Thread Brad King
On Wed, Oct 22, 2014 at 10:53 AM, Bach, Pascal wrote:
> Am I right that when using the reg tool I need to include
> the Wow6432Node again?

Possibly.  I'm not particularly familiar with it, but there
are two of them:

 C:\Windows\System32\reg.exe
 C:\Windows\SysWOW64\reg.exe

Perhaps they take different views.  We don't know which one
will be in the PATH.  I don't think Wow6432Node will exist
on a 32-bit host so you may need to query both with and
without it.

-Brad
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] [PATCH] WINCE: Run Tutorial steps 1-4 as tests for Windows CE

2014-10-22 Thread Bach, Pascal
>
> > I even would prefer to not hardcode the SDK  but I was unable to list key
> entries from the registry.
> >
> > Usually all installed SDKs are listed as subkeys of
> HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs
> in this case it is SDK_AM335X_SK_WEC2013_V310.
> >
> > I think the test would be nicer if it checks for available SDKs and just 
> > picks
> the first.
> >
> > Any ideas how to do this?
> 
> Within a block guarded by if(CMAKE_HOST_WIN32) you could
> use execute_process to run the "reg" command-line tool.
> 

Am I right that when using the reg tool I need to include the Wow6432Node again?

Pascal

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] [PATCH] Windows-GNU, CYGWIN-GNU: Include corresponding windres script

2014-10-22 Thread Brad King
On 10/21/2014 08:08 PM, Timothy Gu wrote:
>  enable_language(RC)
> +include(Platform/CYGWIN-windres)
[snip]
> +include(Platform/Windows-windres)
> +
>  enable_language(RC)

The enable_language(RC) call should internally include those
modules.  In CMakeRCInformation:

 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeRCInformation.cmake;hb=v3.0.2#l29

the line

 include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL)

should do it.

-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


[cmake-developers] [CMake 0015216]: Ninja makes bad phony targets with parallel "sub" directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY

2014-10-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15216 
== 
Reported By:Joseph Lisee
Assigned To:
== 
Project:CMake
Issue ID:   15216
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-22 09:44 EDT
Last Modified:  2014-10-22 09:44 EDT
== 
Summary:Ninja makes bad phony targets with parallel "sub"
directory and custom CMAKE_LIBRARY_OUTPUT_DIRECTORY
Description: 
I have project where the main build directory is on the same level as some "sub"
directories, for example:

  primary/CMakeLists.txt
  secondary/CMakeLists.txt
  primary/build/

When I use the CMAKE_LIBRARY_OUTPUT_DIRECTORY to put all the lib files into
primary/lib the build fails with ninja but keeps working with Make.

The ninja error:

ninja: error: '../lib/libtestlib.so', needed by
'CMakeFiles/main.dir/main.cpp.o', missing and no known rule to make it

Inside build.ninja the library is being built with the absolute path
"/tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so" while other places
refer to it as "../lib/libtestlib.so".  

Adding the following phony rule fixes the error:

build ../lib/libtestlib.so: phony
/tmp/ninja-parallel-sub-test/primary/lib/libtestlib.so

Steps to Reproduce: 
Steps:

 * unzip attached zip files
 * cd primary
 * mkdir build
 * cmake .. -G Ninja
 * ninja

Switching to Make will result in primary/bin/main and primary/lib/libtestlib.so
appearing properly.

Make sure to clean up the primary/bin & primary/lib directory while switching
build systems, if not done ninja will appear to work only because it's not
trying to build the targets.

Additional Information: 
This is broken with the latest git head
fc9041d0249c113cb812d69ee0b8f1411f1eea15, CMake 3.0.2 and CMake 2.8.9.  These
bugs are related: 0014972, 0014414
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-22 09:44 Joseph Lisee   New Issue
2014-10-22 09:44 Joseph Lisee   File Added: ninja-parallel-sub-test.zip 
  
==

-- 

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] [CPack] RPM generator creates %dir for /usr/local/xxx

2014-10-22 Thread Eric Noulard
2014-10-22 14:08 GMT+02:00 Domen Vrankar :

> Moving the conversation to developers mailing list.
>
> More docs on this for 2.8.12:
>>
>> http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
>>
>> I guess that "/usr/local" may be added to
>> CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values.
>>
>> For Domen: see the history of this story here:
>> http://public.kitware.com/Bug/view.php?id=13609
>>
>
> I am familiar with this variable but I haven't noticed until now that not
> all the paths Dubrovskiy Viacheslav
>  listed in bug
> report were removed from auto listing.
>

This was a conservative choice in order to avoid backward compatibilty
issue.

I wasn't sure at that time that all (RPM-based) distros had the whole list
of dirs and I think there was at least some discrepancy between Fedora and
SuSE.
I was planning (in my mind) to craft a distro-specific list of excluded dir
into CPackRPM just in case...

Then ... nothing was done but the CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST*
vars :-(

-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
-- 

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] [CPack] RPM generator creates %dir for /usr/local/xxx

2014-10-22 Thread Domen Vrankar
Moving the conversation to developers mailing list.

More docs on this for 2.8.12:
>
> http://www.cmake.org/cmake/help/v2.8.12/cpack.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
>
> I guess that "/usr/local" may be added to
> CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST default list values.
>
> For Domen: see the history of this story here:
> http://public.kitware.com/Bug/view.php?id=13609
>

I am familiar with this variable but I haven't noticed until now that not
all the paths Dubrovskiy Viacheslav
 listed in bug
report were removed from auto listing.

Currently
/etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib
/usr/lib64 /usr/include
paths are removed.

I can add /usr/local to the list. Are there any additional paths from the
above bug report that anyone thinks should be added?

I would assume that all of the directories from Linux filesystem hierarchy
standard (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard,
http://www.pathname.com/fhs/pub/fhs-2.3.html) should be excluded on Linux
however UNIX filesystem hierarchy has less directories listed on wiki (
http://en.wikipedia.org/wiki/Unix_filesystem) and I am not even certain
that all flavours of UNIX use them.

I think that at least directories that are listed both for Linux and Unix
should be added.

What is the opinion of others?

Domen
-- 

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] Xcode Project: Support for DevelopmentTeam

2014-10-22 Thread Fabian
Thanks for your response.

2014-10-21 15:24 GMT+02:00 Brad King :

> On 10/17/2014 04:16 PM, Fabian wrote:
> > Xcode automatically updates the devices list in the Member Center
>
> Neat.  Please explain the developer workflow you envision to configure
> the value for local build trees.  Would it be something the developer
> should explicitly set in every new tree?  Should there be a common
> configuration in the environment?  Can it be detected programmatically?
>

For some teams, it would probably make sense to set this for every project
in the environment as it gets rid of a bunch of code signing issues.
However, a membership in the developer program is needed and I do not know
an easy way to detect this. An option might be to parse the output of
"certtool y" for "iPhone Distribution:  ()"; notice
the  in brackets.

However, some people (myself included) have to handle memberships in
multiple programs, so there would be some manual selection involved anyway.

> In the CMake source I noticed that 'BuildIndependentTargetsInParallel'
> > is already getting set. This could be extendet to add the
> 'TargetAttributes'
> > section.
>
> Yes, that looks like the right place if you want to try a patch.
>

I looked through the source for a while but I found that for me it would
require too much work to fully patch it, since the target ID also needs to
be read from somewhere and included in the pbxproj. I would highly
appreciate it if you took the time, as it would probably require a fraction
of what I would have to invest.

Regards,
Fabian
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015215]: Please document CMAKE_XCODE_ATTRIBUTE_*

2014-10-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15215 
== 
Reported By:Gregor Jasny
Assigned To:
== 
Project:CMake
Issue ID:   15215
Category:   Documentation
Reproducibility:N/A
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-22 04:52 EDT
Last Modified:  2014-10-22 04:52 EDT
== 
Summary:Please document CMAKE_XCODE_ATTRIBUTE_*
Description: 
Hello,

it took some time to discover how to set global Xcode variables using
CMAKE_XCODE_ATTRIBUTE_*. Please document it briefly and cross link this one and
XCODE_ATTRIBUTE.

Thanks,
Gregor
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-22 04:52 Gregor Jasny   New Issue
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0015214]: Error getting iOS compiler identification on master

2014-10-22 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15214 
== 
Reported By:Gregor Jasny
Assigned To:
== 
Project:CMake
Issue ID:   15214
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2014-10-22 04:49 EDT
Last Modified:  2014-10-22 04:49 EDT
== 
Summary:Error getting iOS compiler identification on master
Description: 
Hello,

If I use cmake to compile the attached example for iOS it fails to get the
compiler identification:


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:

The output was:
65
=== BUILD TARGET CompilerIdC OF PROJECT CompilerIdC WITH THE DEFAULT
CONFIGURATION (Debug) ===

Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform

** BUILD FAILED **


I bisected the master branch and the offending commit is:


0cce556b5fbe629dccee294aeece7c275343ed64 is the first bad commit
commit 0cce556b5fbe629dccee294aeece7c275343ed64
Author: Brad King 
Date:   Tue Apr 29 09:21:00 2014 -0400

Xcode: Use sysroot and deployment target to identify compiler

Use CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to set the Xcode
SDKROOT and MACOSX_DEPLOYMENT_TARGET build settings.  This is necessary
because some versions of Xcode select a different compiler based on
these settings.  We need to make sure the compiler identified during
language initialization matches what will be used for the actual build.


The attached exmaple work with CMake 3.0.x but not with master. But maybe my
toolchain file is incomplete?

Thanks,
Gregor

Steps to Reproduce: 
unpack the attached tarball, create a build directory and run:


~/src/cmake/bin/cmake -GXcode  -DCMAKE_TOOLCHAIN_FILE=../iOS.toolchain.cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error in :
  No CMAKE_C_COMPILER could be found.



CMake Error in :
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!


Additional Information: 
Xcode 6.1 on OSX 10.10 (but fails with Xcode 5.1.1, too)
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2014-10-22 04:49 Gregor Jasny   New Issue
2014-10-22 04:49 Gregor Jasny   File Added: cmakebug.tar.gz
==

-- 

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