Re: [cmake-developers] Extracting target metadata, IDE integration
Aleix Pol wrote:
> Hi,
> I would like to propose this as a final version of this patch.
> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
>
> I have a working proof of concept in KDevelop already I'm quite happy
> with.
>
> Any thoughts?
Just some quick ones:
1) Getting the right sources:
Consider this:
cmake_minimum_required(VERSION 2.8)
project(cmaketest)
add_custom_command(
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/other.cpp"
COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_CURRENT_SOURCE_DIR}/bar.cpp"
"${CMAKE_CURRENT_BINARY_DIR}/other.cpp"
MAIN_DEPENDENCY "${CMAKE_CURRENT_SOURCE_DIR}/bar.cpp"
)
file(GENERATE
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/somefile.cpp"
CONTENT "
static const char all_srcs[] = \"$\";\n"
)
add_executable(foo
main.cpp
"${CMAKE_CURRENT_BINARY_DIR}/other.cpp"
somefile.txt
foo.h
)
After running cmake:
$ cat somefile.cpp
static const char all_srcs[] =
"main.cpp;/home/stephen/dev/src/playground/cmake/build/other.cpp;somefile.txt;foo.h;/home/stephen/dev/src/playground/cmake/bar.cpp";
You would get the same result with your patch: "bar.cpp" is a 'SOURCE', but
it is not an 'object source'. It is not compiled into the target.
CMake knows that, and provides cmGeneratorTarget::GetObjectSources to get
'the list of sources compiled into objects by this buildsystem'. You should
list that in your JSON instead.
You might also make use of GetHeaderSources and GetExtraSources at least to
cover foo.h and somefile.txt too, and probably GetExternalObjects too.
2) The final patch will need to have unit tests and documentation.
3) Did you find any of the feedback from the Creator or CLion guys relevant?
I'd have to review the rest of the thread again to see if there's anything
else which should be addressed already by this iteration of the patch.
4) I won't be able to do a complete review before January.
Thanks!
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Wed, Oct 15, 2014 at 1:46 AM, Aleix Pol wrote: > On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer wrote: >> >> Brad King wrote: >> > On 10/01/2014 07:46 PM, Aleix Pol wrote: >> > > I'm very interested in getting this in and iterating forward. >> > > >> > > Any comments? How do changes get integrated? >> > >> > My main concern is that the format has not been proven with a >> > corresponding implementation of an actual IDE/plugin to use it. >> > Once we start producing a format changing it later will be >> > problematic for compatibility. Even though we added a version >> > number to the file, an IDE might not be updated along with a >> > CMake that produces a newer version. >> >> This probably needs a way to query for the IDE which versions the given >> CMake >> version supports, no? Otherwise a newer IDE may request version 3 and just >> get >> nothing because the CMake binary only supports 1 and 2. >> >> Eike >> -- > > > If it's not available then it should just error out. > > Aleix > > PS: I'm alive, working on this, when I get some free time Hi, I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch I have a working proof of concept in KDevelop already I'm quite happy with. Any thoughts? Aleix -- 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 0015319]: Documentation clarification
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15319 == Reported By:Craig Hicks Assigned To: == Project:CMake Issue ID: 15319 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-12-18 15:57 EST Last Modified: 2014-12-18 15:57 EST == Summary:Documentation clarification Description: The manual entry -G "MinGW Makefiles" on http://www.cmake.org/cmake/help/v2.8.12/cmake.html#gen%3aMinGWMakefiles is ambiguous: MinGW Makefiles: Generates a make file for use with mingw32-make. The makefiles generated use cmd.exe as the shell. They do not require msys or a unix shell. Should be changed to : MinGW Makefiles: Generates a make file for use with mingw32-make. The makefiles generated use cmd.exe as the shell. They are not compatible msys or a unix shell. "cmake" should not be invoked from msys or unix shells when "MinGW Makefiles" is specified as the generator. Steps to Reproduce: Invoking (cmake -G "MinGW Makefiles" ...) from msys shell always fails in many ways. Additional Information: Obvious only once you know it. The wording "does not require msys or a unix shell" could be interpreted as implying that ", however they can be used". As background, mingw32-make did not come with the minwg 64 bit gcc 4.8.2 downloaded from sourceforge. It seemed correct that cmake would require "MinGW Makefiles" for the mingw compiler. However, cmake could not find a make program, but since I had make sitting around under msys, I just specified that. If the manual had been more explicit, it would have saved your novice user a lot of time. Trolling the web for advice, it seems there are many folks who have encountered the same problem. == Issue History Date ModifiedUsername FieldChange == 2014-12-18 15:57 Craig HicksNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On 2014-12-18 11:30, Ruslan Baratov via cmake-developers wrote: > You prefer ".cmake.lock", I prefer "cmake.lock", others prefer > '.lock'/'.cmake'. For me it doesn't really matter. What matter is the > *standard* cmake name. FWIW, I do have a slight preference to using a hidden file :-). > About "implementation complexity": > [...diffs elided...] There's also the documentation, unit tests... I don't think there is appreciable maintenance overhead, or I'd feel more strongly about it. The point was just to consider these things. (Having written it already also makes the question somewhat moot.) > I'm the one who will use this feature without timeouts (it's impossible > to predict some). E.g. cmake instance will run ExternalProject_Add with > Qt building for > 4 hours, should I set the timeout so my jenkins jobs > will crash? Or should I print waiting message every second? I'd print *one* message if the lock has not been obtained "quickly". Even in the situation you describe, if I were writing the lock, I would probably wrap it in a helper to print why it's waiting (or else always print a message before trying to get the lock and once the lock is held), just so that it's obvious from the logs if a build is stuck waiting on the lock or stuck for some other reason. That said... I think you've convinced me that if you need a lock with no timeout, it should *always* generate status messages, which can more reasonably be punted to the CMakeLists.txt author. -- Matthew -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 18-Dec-14 01:49, Matthew Woehlke wrote:
On 2014-12-17 16:58, Ruslan Baratov via cmake-developers wrote:
On 17-Dec-14 21:11, Matthew Woehlke wrote:
On 2014-10-13 10:39, Brad King wrote:
On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
Locking directory is equivalent to locking file `cmake.lock` in
directory "/path/to/shared/directory/":
I think this can be activated buy a DIRECTORY option.
Why do we need even that? Can't CMake just test if the lock target is a
directory?
I've used boost.interprocess as a hint for implementation, as far as I
know boost::interprocess::file_lock is not able to lock directories:
terminate called after throwing an instance of
'boost::interprocess::interprocess_exception'
what(): Is a directory
I'm not saying that it's not possible, just trying to use well-known
cross-platform solution.
Locking a directory "as such" may not be possible (that wouldn't
surprise me). That's not what I meant, though; what I meant is, rather
than make the user say "this is a directory" to instead lock a special
file name in the directory, just have CMake check if the path is a
directory and then use that logic implicitly.
Okay, now I see what you mean :)
Requiring the user to
specify seems superfluous when it's trivial for CMake to just check.
Example:
file(LOCK /path/to/file) # lock /path/to/file
file(LOCK /path/to) # lock /path/to/.cmake_lock
`file(LOCK /path/to/file DIRECTORY)` and `file(LOCK /path/to/directory)`
will report an error instead of silently lock creation.
(And before anyone mentions it, I have limited sympathy for someone
locking a non-existing directory and then later trying to create it.
Don't do that :-). I'm having a very hard time coming up with a reason
why one wouldn't just create the directory first to ensure it exists.)
Just for your information:
* there is no sub-option RECURSIVE for command `file(MAKE_DIRECTORY
...)`, so all intermediate directories will be always created if they
not exist.
* command `file(WRITE "/path/to/some/file.txt" "some info") will create
all directories too
* command `install` create all directories. E.g. if some developer
(well, bad developer) will hardcode '/usr/local' in
CMAKE_INSTALL_PREFIX, binaries will be installed into `X:/usr/local` on
windows.
For that matter, do we even *need* this feature? If I want to lock a
"directory", is it worth the extra implementation complexity just to
save me inventing some arbitrary name for a lock file?
You prefer ".cmake.lock", I prefer "cmake.lock", others prefer
'.lock'/'.cmake'. For me it doesn't really matter. What matter is the
*standard* cmake name.
About "implementation complexity":
@@ -3512,7 +3512,6 @@ bool cmFileCommand::HandleLockCommand(
- bool directory = false;
@@ -3535,10 +3534,6 @@ bool cmFileCommand::HandleLockCommand(
-if (args[i] == "DIRECTORY")
- {
- directory = true;
- }
@@ -3617,11 +3612,6 @@ bool cmFileCommand::HandleLockCommand(
- if (directory)
-{
-path += "/cmake.lock";
-}
p.s. For a lock with no timeout, maybe there can be a built-in timeout
after which CMake displays a message what it's trying to do, so that it
doesn't just hang mysteriously.
You can use `message` command:
message(STATUS "Try to lock ${file}")
file(LOCK ${file})
or more complex (more user-friendly):
while(TRUE)
file(LOCK "${file}" RESULT is_locked TIMEOUT 5)
if(is_locked)
message("Locked. ${resource_info}")
break()
endif()
string(TIMESTAMP time_now "%S/%M")
message("[${time_now}] Lock failed, retry... (file: ${file})")
endwhile()
Sure. I was just thinking out loud if folks are worried about CMake
"mysteriously" hanging, this (implemented in CMake proper) would be an
option to allay those concerns.
You can use `file(LOCK ...` as a base block for creation more
complex/verbose locks (i.e. you can add CMakeLockHelpers extra module),
I don't see any implementation defects that can't you allow to do one.
*Developers* do the "mysterious" stuff, not cmake. You can write:
while(TRUE)
endwhile()
so should we print extra message on entering `while`?
Though it would be the nice feature if you can read some info about
lockers. E.g. `CMAKE_BINARY_DIR`, username, pid and timestamp. But this
require a lot of work: lock new file for writing (cmake.lock-info),
write some info (what format?), unlock (allow other process read info
file) and so on.
(I'd also encourage anyone writing
locks, especially with no time out, to always say what they're doing
first :-). But that's somewhat a separate issue.)
I'm the one who will use this feature without timeouts (it's impossible
to predict some). E.g. cmake instance will run ExternalProject_Add with
Qt building for > 4 hours, should I set the timeout so my jenkins jobs
will crash? Or should I print waiting message every second? What about >
14400 lines of useless/endless logs? The imp
[cmake-developers] [CMake 0015318]: cmComputeLinkDepends.cxx fils to compile
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15318 == Reported By:Fritz H Assigned To: == Project:CMake Issue ID: 15318 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-12-18 17:14 CET Last Modified: 2014-12-18 17:14 CET == Summary:cmComputeLinkDepends.cxx fils to compile Description: os: solaris 10, compiler: sunstudio 12.1 file Source/cmComputeLinkDepends.cxx fails to compile, error: line 270: Error: Cannot use std::reverse_iterator to initialize std::reverse_iterator. line 271: Error: Cannot use std::reverse_iterator to initialize std::reverse_iterator. i am not an expert in c++, but the following change at least satisfied the compiler: --- cmake-3.1.0_orig/Source/cmComputeLinkDepends.cxx Mon Dec 15 21:07:43 2014 +++ cmake-3.1.0/Source/cmComputeLinkDepends.cxxThu Dec 18 16:17:00 2014 @@ -266,7 +266,7 @@ // Iterate in reverse order so we can keep only the last occurrence // of a shared library. std::set emmitted; - for(std::vector::const_reverse_iterator + for(std::vector::reverse_iterator li = this->FinalLinkOrder.rbegin(), le = this->FinalLinkOrder.rend(); li != le; ++li) == Issue History Date ModifiedUsername FieldChange == 2014-12-18 17:14 Fritz HNew 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 0015317]: cmake-3.0.1: failing bootstrap on solaris 10
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15317
==
Reported By:Fritz H
Assigned To:
==
Project:CMake
Issue ID: 15317
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2014-12-18 15:34 CET
Last Modified: 2014-12-18 15:34 CET
==
Summary:cmake-3.0.1: failing bootstrap on solaris 10
Description:
command ./bootstrap immediately fails on solaris 10; error message:
./bootstrap: syntax error at line 148: `!' unexpected
solution:
--- cmake-3.1.0_orig/bootstrap Mon Dec 15 21:07:45 2014
+++ cmake-3.1.0/bootstrap Thu Dec 18 15:21:44 2014
@@ -145,7 +145,9 @@
cmake_machine_parisc=true
fi
elif ${cmake_system_hpux}; then
- if !(uname -m | grep ia64 >/dev/null 2>&1); then
+ if (uname -m | grep ia64 >/dev/null 2>&1); then
+:
+ else
cmake_machine_parisc=true
fi
fi
==
Issue History
Date ModifiedUsername FieldChange
==
2014-12-18 15:34 Fritz HNew Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Minimal compiler requirements for CMake itself
On 12/18/2014 08:44 AM, Rolf Eike Beer wrote: >> I expected the oldest supported version of Visual Studio to be 6.0, but >> that one fails to build CMake. > > IIRC 6.0 was able to build CMake up to 3.0, but then it was dropped as > compiler to build CMake. Steven? Brad? Support for building CMake itself with VS 6 and 7.0 (2002) was dropped recently in 'master' and is not a requirement for future contributions. It still builds with VS 7.1 (2003). > I have a dashboard that builds CMake using gcc 3.4 > IIRC 2.95 is also still supported. I don't think anyone is submitting a dashboard with 2.95 anymore. The general answer is that contributions must build cleanly on the compilers submitting to the nightly dashboard. Note that some of them are not actually building CMake anymore, but merely running the test suite to make sure targeting older compilers still works. These include: - Borland 5.x - OpenWatcom - VS 6, 7.0 They are all testing CMake binaries built with newer compilers. -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 3.1 Android - generator expressions and output names
Great, thank you! Robert, could you please try the nightly to see if there are any further issues preventing you from using the latest Nsight Tegra? -Dmitry -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Wednesday, December 17, 2014 7:20 PM To: Dmitry Polyanitsa Cc: Robert Goulet; cmake-developers@cmake.org Subject: Re: [cmake-developers] CMake 3.1 Android - generator expressions and output names On 12/17/2014 09:22 AM, Dmitry Polyanitsa wrote: > adds ANDROID_API_MIN/CMAKE_ANDROID_API_MIN which will allow you to set > the Min Android API Level in your projects. Thanks. I've applied the patch and merged for testing: Add 'ANDROID_API_MIN' target property to set Android Target MIN API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eeaa25e5 This will be available in the next nightly binaries that appear here: http://www.cmake.org/files/dev/?C=M;O=D We're long past the freeze for 3.1 features so this will be in 3.2. -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
[cmake-developers] [CMake 0015316]: Generation of Eclipse project does not provide support for c++ 11
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15316
==
Reported By:lucaghera
Assigned To:
==
Project:CMake
Issue ID: 15316
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-12-18 08:46 EST
Last Modified: 2014-12-18 08:46 EST
==
Summary:Generation of Eclipse project does not provide
support for c++ 11
Description:
I’m writing a CMake file for a project that should be compiled both in Ubuntu
and OS X.
I want to use eclipse as IDE, gcc and C++ 11.
I read different threads that suggest how to enable C++ 11 in eclipse.
According to them I included these lines in my CMake:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall")
if (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4")
set(CMAKE_CXX_COMPILER_ARG1 "-std=c++11" CACHE STRING "C++ version for
eclipse"
FORCE)
set(CMAKE_ECLIPSE_VERSION "4.3" CACHE STRING "Eclipse version" FORCE)
endif (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4”)
However, eclipse still set a wrong value for the symbol __cplusplus (199711L
instead of 201103L I guess). In the generated file .cproject this should be the
line (in my
case 265)
For this reason eclipse is not able to index C++ 11 features such as shared
pointer.
Therefore I get a syntax error also if the code compiles.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-12-18 08:46 lucaghera New Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Minimal compiler requirements for CMake itself
Am Donnerstag, 18. Dezember 2014, 12:23:38 schrieb Daniel Pfeifer: > Hi, > > I would like to know what the oldest versions of GCC and Visual Studio are > that should be able to compile the CMake source code. I was unable to find > any information about that. > > I expected the oldest supported version of Visual Studio to be 6.0, but > that one fails to build CMake. IIRC 6.0 was able to build CMake up to 3.0, but then it was dropped as compiler to build CMake. Steven? Brad? I have a dashboard that builds CMake using gcc 3.4, IIRC 2.95 is also still supported. Greetings, Eike signature.asc Description: This is a digitally signed message part. -- 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] Minimal compiler requirements for CMake itself
Hi, I would like to know what the oldest versions of GCC and Visual Studio are that should be able to compile the CMake source code. I was unable to find any information about that. I expected the oldest supported version of Visual Studio to be 6.0, but that one fails to build CMake. Don't get me wrong. I would not be unhappy if building CMake required the latest and greatest compilers and language features. I just want to know which compilers I need to be support when I contribute code. cheers, Daniel -- 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
