Re: [cmake-developers] Ninja windows
On Fri, Mar 9, 2012 at 3:24 AM, Peter Collingbourne pe...@pcc.me.uk wrote: On Tue, Mar 06, 2012 at 03:56:24PM -0500, Bill Hoffman wrote: On 3/6/2012 1:29 PM, Peter Collingbourne wrote: We can certainly do that, but the ninja binary would need to be switched as soon as we get around to using rspfile in Ninja (and no sooner). OK, so is there a ninja binary that I can download right now that will work if I change the cmake files for cmake to build the ninja generator on windows? If so, where is it? My idea is to try it on my machine. If it works I will push the change into next that enables ninja on windows and setup a dashboard that pulls ninja from that spot each night. When cmake is changed to work with master ninja if someone updates that binary, then it will pull that and just work. That is what I have been doing with jom. That would be Peter Kummel's ninja. But what I would suggest we do, as I suggested before, is to use an internal variable to turn on the Ninja generator on Windows and Mac. This way, we can safely merge ninja-generator into master without confusing users on Windows or Mac by shipping a non-working Ninja generator in the next release, while keeping the ability to test (on the dashboard and otherwise). I have no idea what the timeframe for the Windows and Mac people is, but I really would like the Ninja generator to be available on non-Windows/Mac platforms in 2.8.8. Sounds fair enough. -- Nicolas Desprès -- 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 0013032]: Support the option Use Library Dependency Inputs in Visual Studio 2005+
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13032 == Reported By:Zahary Karadjov Assigned To: == Project:CMake Issue ID: 13032 Category: CMake Reproducibility:always Severity: tweak Priority: normal Status: new == Date Submitted: 2012-03-09 05:24 EST Last Modified: 2012-03-09 05:24 EST == Summary:Support the option Use Library Dependency Inputs in Visual Studio 2005+ Description: The build times of Visual Studio CMake generated projects could be significantly improved if 1) All dependent static libraries of an executable are listed as dependencies in Visual Studio 2) The Linker-General-Use Library Dependency Inputs option is enabled. Reference Information: http://msdn.microsoft.com/en-us/library/024awkd1(v=vs.80).aspx Use Library Dependency Inputs In a large project, when a dependent project produces a .lib file, incremental linking is disabled. If there are many dependent projects that produce .lib files, building the application can take a long time. When this property is set to Yes, the project system links in the .obj files for .libs produced by dependent projects, thus enabling incremental linking. http://blogs.msdn.com/b/vcblog/archive/2010/05/03/flexible-project-to-project-references.aspx http://code.google.com/p/chromium/wiki/WindowsIncrementalLinking http://www.xoreax.com/webhelp/pages/advanced_incredilink.htm == Issue History Date ModifiedUsername FieldChange == 2012-03-09 05:24 Zahary KaradjovNew 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
[cmake-developers] [CMake 0013033]: Enhance verbosity of tests failing with OTHER_FAULT on windows
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13033 == Reported By:ngladitz Assigned To: == Project:CMake Issue ID: 13033 Category: CTest Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-03-09 10:24 EST Last Modified: 2012-03-09 10:24 EST == Summary:Enhance verbosity of tests failing with OTHER_FAULT on windows Description: I'm not sure how (or if this is even possible) but it would be helpful if the ctest reports could include more information on why a test failed when reporting OTHER_FAULT. When I'm at the computer running the tests I get e.g. a message box that reports that there is a specific DLL missing but when ctest runs scheduled through CDash that information is lost. == Issue History Date ModifiedUsername FieldChange == 2012-03-09 10:24 ngladitz New 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
Re: [cmake-developers] Ninja windows
On 09.03.2012 10:40, Nicolas Desprès wrote: On Fri, Mar 9, 2012 at 3:24 AM, Peter Collingbournepe...@pcc.me.uk wrote: On Tue, Mar 06, 2012 at 03:56:24PM -0500, Bill Hoffman wrote: On 3/6/2012 1:29 PM, Peter Collingbourne wrote: We can certainly do that, but the ninja binary would need to be switched as soon as we get around to using rspfile in Ninja (and no sooner). OK, so is there a ninja binary that I can download right now that will work if I change the cmake files for cmake to build the ninja generator on windows? If so, where is it? My idea is to try it on my machine. If it works I will push the change into next that enables ninja on windows and setup a dashboard that pulls ninja from that spot each night. When cmake is changed to work with master ninja if someone updates that binary, then it will pull that and just work. That is what I have been doing with jom. That would be Peter Kummel's ninja. But what I would suggest we do, as I suggested before, is to use an internal variable to turn on the Ninja generator on Windows and Mac. This way, we can safely merge ninja-generator into master without confusing users on Windows or Mac by shipping a non-working Ninja generator in the next release, while keeping the ability to test (on the dashboard and otherwise). I have no idea what the timeframe for the Windows and Mac people is, but I really would like the Ninja generator to be available on non-Windows/Mac platforms in 2.8.8. Sounds fair enough. Yes, please enable the ninja generator for Linux in 2.8.8. I don't think I will fix the cmake-windows support soon and don't know if there is anyone else working on it. Maybe having ninja support on Linux attracts interested people also on the other platforms. (and I assume Peter C. gets really annoyed if the ninja support will be postponed again) Peter -- 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] Rename Ninja generator?
On 09.03.2012 03:34, Peter Collingbourne wrote: On Thu, Mar 08, 2012 at 05:44:09PM -0500, Bill Hoffman wrote: Thoughts? Hi Bill, I thought about this for a while and I decided that this probably isn't a good idea for a few reasons: 1) It is inaccurate. The Ninja generator uses a fundamentally different approach to generating build files and I think that should be reflected in the name. 2) If we go with your suggestion, things will continue to work if what the project does for Make happens to also be appropriate for Ninja. But that isn't always the case -- if the project cares about which generator is being used then it may well be doing something specific to the Makefile generator (such as relying on the fact that CMake builds recursive makefiles by running the build program in a subdirectory, or using $(MAKE) -- you can see an example of that in ExternalProject.cmake). In that case things would break unless the conditional excludes Ninja: IF(CMAKE_GENERATOR MATCHES Makefiles AND NOT CMAKE_GENERATOR MATCHES Ninja) Things like that need to be decided on a case by case basis by the project developer and I don't see any reason to favour one scenario over the other. All things being equal I would err on the conservative side and say that Ninja shouldn't receive any special treatment from projects by default -- if projects need the Ninja generator to get the same special treatment, they can match Ninja explicitly. 3) Less typing :) (Though one idea I had for improving the user interface for the -G option was to allow the argument to be matched case insensitively, and for unambiguous prefixes to be expanded. So for example you could say -G nmake which would be disambiguated to NMake Makefiles, but -G n would return an error since it matches both Ninja and NMake). Yes, please don't call it a Makefile when it is definitely NOT a Makefile. I also like the short -GNinja. -GVisual Studio 9 2008 is really to long as command line argument. Peter -- 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] ninja bug on windows
I am seeing that ninja always wants to relink the executables for me every time it is run. The output is this: $ ninja [1/9] Linking C static library Utilities\cmlibarchive\libarchive\cmlibarchive.lib [2/9] Linking CXX executable bin\cmake.exe [3/9] Linking CXX executable bin\cmw9xcom.exe [4/9] Linking CXX executable bin\cpack.exe [5/9] Linking CXX executable bin\ctest.exe [6/9] Linking CXX executable Tests\CMakeLib\CMakeLibTests.exe [7/9] Generating ../Docs/ctest.txt [8/9] Generating ../Docs/cpack.txt [9/9] Generating ../Docs/cmake.txt Looks like the problem is libarchive getting recreated each time. -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
Re: [CMake] Automatically add a revision number to the CPack installer name
2012/3/9 Glenn Ramsey g...@componic.co.nz: Thanks Eric, this lead me to a solution that works for me, where the revision number is updated at build time. For future reference here is what I did: [...] This is a nice and relatively easy solution. Thank you for sharing the final solution. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to modify scope of imported library
Hi,
I was solving a similar problem in our setup at work. The problem was
that the parent couldn't know in advance which libraries will be
imported by children. Conceptually speaking, I solved this by creating
my own set of global properties which contain all necessary details
about the libraries imported. These properties are appended to when a
child imports a library, and then scanned once more in the parent and
imported again:
child CMakeLists.txt:
...
ADD_LIBRARY(someLib IMPORTED)
SET_PROPERTY(GLOBAL APPEND PROPERTY imported_libraries someLib)
# more SET_PROPERTY calls to store lib's location etc.
...
parent CMakeLists.txt:
...
DEFINE_PROPERTY(GLOBAL PROPERTY imported_libraries ...)
...
ADD_SUBDIRECTORY(child)
...
GET_PROPERTY(GLOBAL PROPERTY imported_libraries impLibs)
# more GET_PROPERTY calls to retrieve libs' locations etc.
FOREACH(lib IN LISTS impLibs)
ADD_LIBRARY({$lib} IMPORTED)
ENDFOREACH()
...
Petr
On Fri, Mar 9, 2012 at 8:42 AM, Andreas Pakulat ap...@gmx.de wrote:
On 08.03.12 19:24:00, Cong Ma wrote:
Hi,
Imported library has scope in the directory in which it is created and
below.
If I want to use this library in parent scope, what should I do?
Add the imported library in the top-level cmake file, not a
subdirectory.
Andreas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Code and API review request for Qt5 CMake files
On 03/05/2012 02:04 AM, Stephen Kelly wrote:
Michael Hertling wrote:
* Currently there is no Qt5Config.cmake.
Such a thing could probably exist and use the FIND_COMPONENTS to find
what was requested. [...]
Hi there,
Thank you for your insights on this issue. Do you have any other insights
into other issues I raised in the original post?
No, I just picked out the Qt5Config.cmake ones. Perhaps later...
Absolutely, I would greatly appreciate a well-designed and component-
aware Qt5Config.cmake.
Yes. This thread confirms though that it is not a simple issue as I wrote
before :)
Indeed, component-aware find modules / config files are significantly
more complicated than component-unaware ones. Typical questions are:
- Accumulation of result variables
- Handling of unknown components
- Searching unrequested components
- Interpretation of *_FOUND variable
- Untouched *_*_FOUND variables
- Impact of REQUIRED/QUIET
In general, there might be reasons why a multi-
component package's components that are to be used together should not
be requested in separate FIND_PACKAGE() invocations, see [1] and look
for package X with components A and B. However, I don't know if Qt5
will be the first example of that kind.
Your exact example is not covered by the Qt5 situation as far as I can tell.
However, similar issues already crop up (with Qt4 based systems). Can you
confirm whether you are aware of the issues around code like this regarding
the use of -DQT_GUI_LIB with the foo target so I know if I need to explain
it and whether we are on the same page? :
find_package(Qt4 REQUIRED Gui Test)
include(${QT_USE_FILE})
add_executable(bar ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES})
add_executable(foo ${QT_QTCORE_LIBRARIES} ${QT_QTTEST_LIBRARIES})
Do you mean the appearance of -DQT_GUI_LIB during foo's compilation
although the latter doesn't need it? If so, this is a, say, inverse
version of what I had in mind: An unnecessary -D, possibly enabling
undesired code in headers during the compilation. If not, could you
explain it once more in another way? ;-)
Actually, my general consideration in this regard is: There might be
quite subtle relations among a package's components, beyond the usual
B-needs-A one. Find modules and config files suit perfectly to handle
such relations, but in order to do this, they must be supplied with
sufficient information. So, all components going to be used together
should be requested together, and if one wants to use a different set
of components, one should request them with a separate FIND_PACKAGE()
call. In this way, a find module / config file is equipped to provide
optimal results, i.e. the exact settings to enable the requested set
of components - no more, no less. In fact, settings like QT_GUI_LIB
made me reason about this issue for the first time, though I still
do not know a real-life example for a -D which is related solely
to a combination of components, or anything else of that kind.
Referring to Qt5_XYZ_FOUND alone is not reliable because this variable
wouldn't have received a definite value if Qt5Config.cmake hasn't been
found by FIND_PACKAGE().
I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset
variables are well defined as false in the if() command. Maybe I
misunderstand you?
Maybe. ;-) What ensures the variables had already been unset before
FIND_PACKAGE() was invoked? If they had evaluated as TRUE - for what-
ever reason - and FIND_PACKAGE() fails to load Qt5Config.cmake, they
will still be TRUE afterwards although Qt5 has not been found at all.
IMO, if FIND_PACKAGE() fails to locate a package, one shouldn't rely
on the assumption that any variable except *_FOUND has a reasonable
value. Thus, in order to play safe, one should access the variables
only after checking the package's successful detection, e.g. like:
IF(Qt5_FOUND AND Qt5_Xml_FOUND)
This consideration is one of my major objections against the proposal
w.r.t. permitting config files to set *_FOUND by themselves. As it is
suggested, it would result in *_FOUND set to FALSE if just a component
is missing, so one can not use *_FOUND anymore to detect the package's
presence. Instead, one would need to apply other means, e.g. the *_DIR
variable set by FIND_PACKAGE() in config mode, but that doesn't work in
module mode, AFAIK. Anyway, I am afraid this will complicate the usage
of FIND_PACKAGE() and promote the inconsistencies among find modules
and config files.
I.e., the user would refer to this variable's
value before the FIND_PACKAGE() call; probably, that's not expected.
Why would the user refer to Qt5_Xml_FOUND before
find_package(Qt5 REQUIRED Xml)
?
(S)he wouldn't - bad wording of mine. A better one is: The user would
see the value the variable already had when FIND_PACKAGE() was called.
[...] At least, I think
something like qt5_use_package is a better idea anyway.
First of all, I definitely agree to your criticism of
[CMake] How to correctly set dependencies for header files generated in another directory
Hi,
I'm trying to figure out how to correctly set up dependencies for
generated header files.
I have prepared an example setup here: http://github.com/usovalx/cmake_test.git
Quick summary:
root/CMakeLists.txt:
add_subdirectory(sub1)
add_subdirectory(sub2)
sub2/CMakeLists.txt:
add_custom_command(
OUTPUT tt.h tt.c
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/gen.sh
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
VERBATIM)
add_custom_target(sub2Hxx)
add_dependencies(sub2Hxx tt.h tt.c)
add_library(t2 gen.sh tt.c tt.h)
add_dependencies(t2 sub2Hxx)
sub1/CMakeLists.txt:
add_executable(t1main.c)
add_dependencies(t1 sub2Hxx)
sub1/main.c:
#include ../sub2/tt.h
Now if I'm trying to build target t1 compilation fails because
generator script didn't run.
What is the correct way to trigger code generation in this case?
--
Best regards,
Alexander.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] UPD: dependencies for header files
Nevrmind -- I just figured out my mistake. -- Best regards, Alexander. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja + CMake on a dashboard?
Where does the Ninja generator currently live? Ie which branch in the sources, etc? I am keen to see support for the Ninja generator on Mac/Linux/Windows and would not mind working on it. Thanks, Steve 2012/3/8 Peter Collingbourne pe...@pcc.me.uk On Wed, Mar 07, 2012 at 07:14:52AM +0100, Nicolas Desprès wrote: On Tue, Mar 6, 2012 at 8:58 PM, Clifford Yapp cliffy...@gmail.com wrote: We *could*, if popular demand is high enough, merge it in anyway and call it experimental to start with, or we could get it right all the way before we merge to 'master' and put it out in an official CMake release. What would be involved with fixing the remaining OSX issues? Do we need CMake changes, ninja changes, both...? Obviously full support would be preferable, unless it won't be happening for quite some time - I would agree that if non-GUI apps won't work on OSX it would be better to limit an activation of Ninja to those platforms where it will Work As Expected. So contrary to what I have said at the beginning of this thread. It seems that merging it master will generate more bug report than patches to fix the issue. If it is the case, I prefer to disable it. I will try to fix them ASAP anyway. It seems that public opinion is against me. Well, I guess we can disable the Ninja generator by default on Mac. Anyone who wants to turn it back on should be able to use an internal CMake variable when building CMake. Thanks, -- Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja + CMake on a dashboard?
On 3/9/2012 12:21 PM, Steven Wilson wrote: Where does the Ninja generator currently live? Ie which branch in the sources, etc? I am keen to see support for the Ninja generator on Mac/Linux/Windows and would not mind working on it. Thanks, Steve The ninja support is in the next branch right now. Where is stands: - Linux seems to be all done - Windows is close, still a few failing tests, and needs to use a special ninja: http://sourceforge.net/projects/cmakescript/files/ninja.exe/download - The Mac needs the most work, as Framework and App bundle creation is not yet implemented. I am working on getting nightly dashboards for all three linux, windows and Mac going. I am going to turn on the ninja build by default on linux, and have an advanced cache option that will default to off for windows and mac. When the next version comes out it will be enabled on all platforms that are passing all the tests (currently only linux). The topic where the work happens is on the stage, and is called stage/ninja-generator. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] math(EXPR) and unary operators
Make sure you set the precedence and associativity of this operator.
Look for the prec declaration and resulting rule at:
http://www.gnu.org/software/bison/manual/html_node/Infix-Calc.html
For example:
/* Bison declarations. */
%token NUM
%left '-' '+'
%left '*' '/'
%left NEG /* negation--unary minus */
%right '^'/* exponentiation */
and
exp: NUM{ $$ = $1; }
| exp '+' exp{ $$ = $1 + $3;}
| exp '-' exp{ $$ = $1 - $3;}
| exp '*' exp{ $$ = $1 * $3;}
| exp '/' exp{ $$ = $1 / $3;}
| '-' exp %prec NEG { $$ = -$2;}
| exp '^' exp{ $$ = pow ($1, $3); }
| '(' exp ')'{ $$ = $2; }
;
Regards,
Juan
On Tue, Mar 6, 2012 at 4:05 PM, George Koehler xkern...@netscape.net wrote:
math(EXPR) rejects expressions with negative numbers. This is awful because
math() can reject its own negative results. For example, this code fails:
math(EXPR negative 1 - 2)
math(EXPR sum 100 + ${negative})
The second expression, 100 + -1, causes an error.
This contradicts cmake --help-command math, which claims, Supported
operators are + - * / % | ^ ~ * / %. They have the same meaning as
they do in c code.
I can write -2 or ~2 in C, but not in CMake. The ~ (bitwise not) seems
impossible to use. My every attempt to use ~ in math() causes an error.
To fix this bug, I taught the grammar about unary operators:
diff --git a/Source/cmExprParser.y b/Source/cmExprParser.y
index 317b0ba..57820ec 100644
--- a/Source/cmExprParser.y
+++ b/Source/cmExprParser.y
@@ -150,6 +150,16 @@ term exp_MOD factor
{$Number$ = $Number1 % $Number3;}
factor:
+value
+{$Number$ = $Number1;}
+|
+exp_MINUS factor
+{$Number$ = -$Number2;}
+|
+exp_NOT factor
+{$Number$ = ~$Number2;}
+
+value:
exp_NUMBER
{$Number$ = $Number1;}
|
I pasted this same patch at http://pastebin.com/7j5Pu3AL
After applying this patch, one must run the bison command from the comment
in cmExprParser.y.
--George Koehler
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to modify scope of imported library
On Friday 09 March 2012, Petr Kmoch wrote: Hi, I was solving a similar problem in our setup at work. The problem was that the parent couldn't know in advance which libraries will be imported by children. Conceptually speaking, I solved this by creating my own set of global properties which contain all necessary details about the libraries imported. These properties are appended to when a child imports a library, and then scanned once more in the parent and imported again: I need to check, but I think with the upcoming 2.8.8 release there will be a new GLOBAL option for add_library(.. IMPORTED), to make the imported target globally visible. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] math(EXPR) and unary operators
George Koehler wrote:
math(EXPR) rejects expressions with negative numbers. This is awful
because math() can reject its own negative results. For example, this
code fails:
math(EXPR negative 1 - 2)
math(EXPR sum 100 + ${negative})
If you are touching this file anyway, do you see any chance of teaching it to
deal with hex numbers, too? When dealing with the OpenSSL version defines I
found out that this is currently not supported.
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to modify scope of imported library
I just did the same thing as Petr, Hopefully, we can do it gracefully with 2.8.8. Thanks~~ On Fri, Mar 9, 2012 at 10:48 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Friday 09 March 2012, Petr Kmoch wrote: Hi, I was solving a similar problem in our setup at work. The problem was that the parent couldn't know in advance which libraries will be imported by children. Conceptually speaking, I solved this by creating my own set of global properties which contain all necessary details about the libraries imported. These properties are appended to when a child imports a library, and then scanned once more in the parent and imported again: I need to check, but I think with the upcoming 2.8.8 release there will be a new GLOBAL option for add_library(.. IMPORTED), to make the imported target globally visible. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- *CONG MA * *skype: cong.ma.curve* * * *CURVE DENTAL* *A Fresh, Web-based Alternative to Dental Software* *www.curvedental.com* -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] OS X Icon file
Hello all,
How do I specify that my icon file (.icns) be installed to the correct
location in an OS X bundle? So far, I've got:
IF ( ${CMAKE_HOST_APPLE} )
message( OS X build )
SET( CMAKE_CXX_FLAGS -m32 ${CMAKE_CXX_FLAGS} )
SET( MACOSX_BUNDLE_INFO_STRING MRIConvert - version 2.0 )
SET( MACOSX_BUNDLE_BUNDLE_VERSION 2.0 )
# Change following line to point to actual icns file in bundle.
SET( MACOSX_BUNDLE_ICON_FILE MRIConvert.icns )
SET( MACOSX_BUNDLE_GUI_IDENTIFIER edu.uoregon.lcni.MRIConvert )
SET( MACOSX_BUNDLE_BUNDLE_NAME MRIConvert )
ENDIF ( ${CMAKE_HOST_APPLE} )
which creates the Info.plist file in the Contents directory. I've also
got MACOSX_BUNDLE specified in my Add_Executable block, so the bundle
hierarchy is created. Google does not know the answer.
Thank you,
--
Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OS X Icon file
SET_SOURCE_FILES_PROPERTIES(${ICON_FILE_PATH} PROPERTIES
MACOSX_PACKAGE_LOCATION Resources)
--
Mike Jackson www.bluequartz.net
On Mar 9, 2012, at 3:46 PM, Chuck Theobald wrote:
Hello all,
How do I specify that my icon file (.icns) be installed to the correct
location in an OS X bundle? So far, I've got:
IF ( ${CMAKE_HOST_APPLE} )
message( OS X build )
SET( CMAKE_CXX_FLAGS -m32 ${CMAKE_CXX_FLAGS} )
SET( MACOSX_BUNDLE_INFO_STRING MRIConvert - version 2.0 )
SET( MACOSX_BUNDLE_BUNDLE_VERSION 2.0 )
# Change following line to point to actual icns file in bundle.
SET( MACOSX_BUNDLE_ICON_FILE MRIConvert.icns )
SET( MACOSX_BUNDLE_GUI_IDENTIFIER edu.uoregon.lcni.MRIConvert )
SET( MACOSX_BUNDLE_BUNDLE_NAME MRIConvert )
ENDIF ( ${CMAKE_HOST_APPLE} )
which creates the Info.plist file in the Contents directory. I've also got
MACOSX_BUNDLE specified in my Add_Executable block, so the bundle hierarchy
is created. Google does not know the answer.
Thank you,
--
Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-3132-g0e31245
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0e3124564216e0a80530a6daca009620834062d4 (commit)
via c7da50da52debd980ec1232dfc2e91b7162f5c84 (commit)
from 1abdfd64cedc84ab18c8f57b2d317e3a23cd35aa (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e3124564216e0a80530a6daca009620834062d4
commit 0e3124564216e0a80530a6daca009620834062d4
Merge: 1abdfd6 c7da50d
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 08:02:49 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 08:02:49 2012 -0500
Merge topic 'ctest-clang-in-xcode' into next
c7da50d CTest: Detect Xcode error Command ... failed with exit code
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7da50da52debd980ec1232dfc2e91b7162f5c84
commit c7da50da52debd980ec1232dfc2e91b7162f5c84
Author: Alexandru Ciobanu a...@rogue-research.com
AuthorDate: Thu Mar 8 18:32:12 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Mar 9 07:59:56 2012 -0500
CTest: Detect Xcode error Command ... failed with exit code
diff --git a/Source/CTest/cmCTestBuildHandler.cxx
b/Source/CTest/cmCTestBuildHandler.cxx
index 34a3e60..27bb06c 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -94,6 +94,7 @@ static const char* cmCTestErrorMatches[] = {
: Invalid argument,
^The project cannot be built\\.,
^\\[ERROR\\],
+ ^Command .* failed with exit code,
0
};
---
Summary of changes:
Source/CTest/cmCTestBuildHandler.cxx |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3134-g778708b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 778708b0459006b8c3fc1492430a2ada82f152cd (commit) via ea4416cf7bca8b3123a5b26d159f7164d727a8e6 (commit) from 0e3124564216e0a80530a6daca009620834062d4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=778708b0459006b8c3fc1492430a2ada82f152cd commit 778708b0459006b8c3fc1492430a2ada82f152cd Merge: 0e31245 ea4416c Author: Brad King brad.k...@kitware.com AuthorDate: Fri Mar 9 09:36:03 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Mar 9 09:36:03 2012 -0500 Merge topic 'ctest-match-valgrind' into next ea4416c CTest: Match valgrind errors with points to (#12922) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea4416cf7bca8b3123a5b26d159f7164d727a8e6 commit ea4416cf7bca8b3123a5b26d159f7164d727a8e6 Author: Alexandru Ciobanu a...@rogue-research.com AuthorDate: Sun Feb 12 23:26:05 2012 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Mar 9 09:32:28 2012 -0500 CTest: Match valgrind errors with points to (#12922) Teach CTest to match valgrind errors of the format Syscall param ... points to uninitialised byte(s). diff --git a/Source/CTest/cmCTestMemCheckHandler.cxx b/Source/CTest/cmCTestMemCheckHandler.cxx index f0a98f9..035aaa9 100644 --- a/Source/CTest/cmCTestMemCheckHandler.cxx +++ b/Source/CTest/cmCTestMemCheckHandler.cxx @@ -679,7 +679,7 @@ bool cmCTestMemCheckHandler::ProcessMemCheckValgrindOutput( bytes in [0-9,]+ blocks are definitely lost in loss record [0-9,]+ of [0-9,]+); cmsys::RegularExpression vgPAR( -== .*Syscall param .* contains unaddressable byte\\(s\\)); +== .*Syscall param .* (contains|points to) unaddressable byte\\(s\\)); cmsys::RegularExpression vgMPK1( == .*[0-9,]+ bytes in [0-9,]+ blocks are possibly lost in loss record [0-9,]+ of [0-9,]+); --- Summary of changes: Source/CTest/cmCTestMemCheckHandler.cxx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3137-gc5d6d48
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c5d6d48e1085d8ebe354a2260006181e4d301036 (commit)
via 05a76d53c0ff99f698760080c2fbde7f1e47cf7a (commit)
via c7bdef5b48fe74f92d75f538e702257e7de1a998 (commit)
from 778708b0459006b8c3fc1492430a2ada82f152cd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5d6d48e1085d8ebe354a2260006181e4d301036
commit c5d6d48e1085d8ebe354a2260006181e4d301036
Merge: 778708b 05a76d5
Author: David Cole david.c...@kitware.com
AuthorDate: Fri Mar 9 13:05:08 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 13:05:08 2012 -0500
Merge topic 'fix-cpack-hdiutil-retry-loops' into next
05a76d5 CPack: Fix retry logic when calls to hdiutil fail
c7bdef5 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05a76d53c0ff99f698760080c2fbde7f1e47cf7a
commit 05a76d53c0ff99f698760080c2fbde7f1e47cf7a
Author: David Cole david.c...@kitware.com
AuthorDate: Fri Mar 9 11:39:01 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Fri Mar 9 11:39:01 2012 -0500
CPack: Fix retry logic when calls to hdiutil fail
The long-standing sporadic failures of CPack tests on the Mac dashboards
are caused by an occasional problem running hdiutil. To compensate for
this, a retry loop was added in the code in a previous commit: a9fa71a4
... but the logic for breaking out of the retry loop was flawed, breaking
out of the loop (and not retrying) when the hdiutil command returns an
error instead of when it returns success.
This commit fixes the flawed logic, bumps up the number of retries from
4 to 10, and adds a half-second delay in between retries.
The delay is specifically added in case a virus checker or spotlight indexer
is temporarily causing the hdiutil failure by hanging onto a newly created
file longer than hdiutil expects it to.
As with all sporadically occurring issues, we'll never know if this is
really fixed all the way. But I'll be happy even if we can only get it to
happen just a bit less often.
diff --git a/Source/CPack/cmCPackOSXX11Generator.cxx
b/Source/CPack/cmCPackOSXX11Generator.cxx
index 75ad640..363ccea 100644
--- a/Source/CPack/cmCPackOSXX11Generator.cxx
+++ b/Source/CPack/cmCPackOSXX11Generator.cxx
@@ -170,23 +170,25 @@ int cmCPackOSXX11Generator::PackageFiles()
\ create -ov -format UDZO -srcfolder \
diskImageDirectory.c_str()
\ \ packageFileNames[0] \;
- int retVal = 1;
cmCPackLogger(cmCPackLog::LOG_VERBOSE,
Compress disk image using command:
dmgCmd.str().c_str() std::endl);
// since we get random dashboard failures with this one
// try running it more than once
- int numTries = 4;
+ int retVal = 1;
+ int numTries = 10;
bool res = false;
while(numTries 0)
{
res = cmSystemTools::RunSingleCommand(dmgCmd.str().c_str(), output,
retVal, 0,
this-GeneratorVerbose, 0);
-if(res retVal)
+if ( res !retVal )
{
numTries = -1;
+ break;
}
+cmSystemTools::Delay(500);
numTries--;
}
if ( !res || retVal )
diff --git a/Source/CPack/cmCPackPackageMakerGenerator.cxx
b/Source/CPack/cmCPackPackageMakerGenerator.cxx
index 0c4b1a6..327c4a6 100644
--- a/Source/CPack/cmCPackPackageMakerGenerator.cxx
+++ b/Source/CPack/cmCPackPackageMakerGenerator.cxx
@@ -319,17 +319,19 @@ int cmCPackPackageMakerGenerator::PackageFiles()
\ \ packageFileNames[0] \;
std::string output;
int retVal = 1;
- int numTries = 4;
+ int numTries = 10;
bool res = false;
while(numTries 0)
{
res = cmSystemTools::RunSingleCommand(dmgCmd.str().c_str(), output,
retVal, 0, this-GeneratorVerbose,
0);
-if(res retVal)
+if ( res !retVal )
{
numTries = -1;
+ break;
}
+cmSystemTools::Delay(500);
numTries--;
}
if ( !res || retVal )
---
Summary of changes:
Source/CPack/cmCPackOSXX11Generator.cxx |8 +---
Source/CPack/cmCPackPackageMakerGenerator.cxx |6 --
Source/kwsys/kwsysDateStamp.cmake |2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
[Cmake-commits] CMake branch, next, updated. v2.8.7-3139-g6dc37e9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6dc37e91431b70c6f4ee55744b26eb103ee067f1 (commit)
via d2d492f492a8a6082345e439a9c15418f0d483db (commit)
from c5d6d48e1085d8ebe354a2260006181e4d301036 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6dc37e91431b70c6f4ee55744b26eb103ee067f1
commit 6dc37e91431b70c6f4ee55744b26eb103ee067f1
Merge: c5d6d48 d2d492f
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Fri Mar 9 14:36:43 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 14:36:43 2012 -0500
Merge topic 'ninja-generator' into next
d2d492f Add a cache option CMAKE_ENABLE_NINJA to enable the ninja generator.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2d492f492a8a6082345e439a9c15418f0d483db
commit d2d492f492a8a6082345e439a9c15418f0d483db
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Fri Mar 9 14:28:21 2012 -0500
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Fri Mar 9 14:28:21 2012 -0500
Add a cache option CMAKE_ENABLE_NINJA to enable the ninja generator.
Make the option default to on, for platforms where CMake passes
all tests with the ninja generator. This is currently only Linux.
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index eb4327c..18f9b8b 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -353,7 +353,18 @@ IF (WIN32)
ENDIF(NOT UNIX)
ENDIF (WIN32)
-if(NOT WIN32)
+# turn on Ninja by default
+set(_CMAKE_DEFAULT_NINJA_VALUE TRUE)
+# turn it off for platforms where it does not pass all the
+# tests
+if(WIN32 OR APPLE)
+ SET(_CMAKE_DEFAULT_NINJA_VALUE FALSE)
+endif()
+SET(CMAKE_ENABLE_NINJA ${_CMAKE_DEFAULT_NINJA_VALUE} CACHE BOOL
+Enable the ninja generator for CMake. currently not fully working for
Windows or OSX)
+MARK_AS_ADVANCED(CMAKE_ENABLE_NINJA)
+IF(CMAKE_ENABLE_NINJA)
+ MESSAGE(STATUS Enable ninja generator.)
SET(SRCS ${SRCS}
cmGlobalNinjaGenerator.cxx
cmGlobalNinjaGenerator.h
@@ -368,7 +379,9 @@ if(NOT WIN32)
cmNinjaUtilityTargetGenerator.h
)
ADD_DEFINITIONS(-DCMAKE_USE_NINJA)
-endif()
+ELSE()
+ MESSAGE(STATUS Disable ninja generator.)
+ENDIF()
# create a library used by the command line and the GUI
ADD_LIBRARY(CMakeLib ${SRCS})
---
Summary of changes:
Source/CMakeLists.txt | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3143-gc8e9707
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c8e97077314e1983b4e3e962da366947a8c9ab61 (commit)
via 0996f2a228a834d75ba9845ea6b899b60eb84712 (commit)
via 67734be8cf4cb7fa1c29ec62a19ef04dd898a08c (commit)
via 4ae7f3656b6ebe7c878716b95ef5eb3d924d4173 (commit)
from 6dc37e91431b70c6f4ee55744b26eb103ee067f1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8e97077314e1983b4e3e962da366947a8c9ab61
commit c8e97077314e1983b4e3e962da366947a8c9ab61
Merge: 6dc37e9 0996f2a
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 15:14:02 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 15:14:02 2012 -0500
Merge topic 'cleanup-object-file-names' into next
0996f2a Hide Makefile local object info inside local generator
67734be VS: Simplify object name computation
4ae7f36 Remove unused partial OBJECT_FILES property implementation
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0996f2a228a834d75ba9845ea6b899b60eb84712
commit 0996f2a228a834d75ba9845ea6b899b60eb84712
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Mar 6 14:42:40 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Mar 8 07:58:52 2012 -0500
Hide Makefile local object info inside local generator
Make cmLocalUnixMakefileGenerator3::LocalObjectInfo private and add
cmLocalUnixMakefileGenerator3::AddLocalObjectFile to create entries.
diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx
b/Source/cmLocalUnixMakefileGenerator3.cxx
index 5cc4e1c..d032a93 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -145,6 +145,20 @@ void cmLocalUnixMakefileGenerator3::Generate()
}
//
+void cmLocalUnixMakefileGenerator3::AddLocalObjectFile(
+ cmTarget* target, cmSourceFile* sf, std::string objNoTargetDir,
+ bool hasSourceExtension)
+{
+ if(cmSystemTools::FileIsFullPath(objNoTargetDir.c_str()))
+{
+objNoTargetDir = cmSystemTools::GetFilenameName(objNoTargetDir);
+}
+ LocalObjectInfo info = this-LocalObjectFiles[objNoTargetDir];
+ info.HasSourceExtension = hasSourceExtension;
+ info.push_back(LocalObjectEntry(target, sf-GetLanguage()));
+}
+
+//
void cmLocalUnixMakefileGenerator3::GetIndividualFileTargets
(std::vectorstd::string targets)
{
diff --git a/Source/cmLocalUnixMakefileGenerator3.h
b/Source/cmLocalUnixMakefileGenerator3.h
index 4754f11..4bde082 100644
--- a/Source/cmLocalUnixMakefileGenerator3.h
+++ b/Source/cmLocalUnixMakefileGenerator3.h
@@ -225,24 +225,9 @@ public:
// write the target rules for the local Makefile into the stream
void WriteLocalAllRules(std::ostream ruleFileStream);
- struct LocalObjectEntry
- {
-cmTarget* Target;
-std::string Language;
-LocalObjectEntry(): Target(0), Language() {}
-LocalObjectEntry(cmTarget* t, const char* lang):
- Target(t), Language(lang) {}
- };
- struct LocalObjectInfo: public std::vectorLocalObjectEntry
- {
-bool HasSourceExtension;
-bool HasPreprocessRule;
-bool HasAssembleRule;
-LocalObjectInfo():HasSourceExtension(false), HasPreprocessRule(false),
- HasAssembleRule(false) {}
- };
- std::mapcmStdString, LocalObjectInfo const GetLocalObjectFiles()
-{ return this-LocalObjectFiles;}
+ void AddLocalObjectFile(cmTarget* target, cmSourceFile* sf,
+ std::string objNoTargetDir,
+ bool hasSourceExtension);
std::vectorcmStdString const GetLocalHelp() { return this-LocalHelp; }
@@ -298,9 +283,6 @@ protected:
void WriteTargetRequiresRule(std::ostream ruleFileStream,
cmTarget target,
const std::vectorstd::string objects);
- void WriteObjectConvenienceRule(std::ostream ruleFileStream,
- const char* comment, const char* output,
- LocalObjectInfo const info);
std::string GetObjectFileName(cmTarget target,
const cmSourceFile source,
@@ -375,7 +357,27 @@ private:
bool SkipPreprocessedSourceRules;
bool SkipAssemblySourceRules;
+ struct LocalObjectEntry
+ {
+cmTarget* Target;
+std::string Language;
+LocalObjectEntry(): Target(0), Language() {}
+LocalObjectEntry(cmTarget* t, const char* lang):
+
[Cmake-commits] CMake branch, next, updated. v2.8.7-3145-g0a505f3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0a505f3f05dab1582d9a09fccc1855587044eb72 (commit)
via 15754a55688b1f51dd0200551a84c772ce598f39 (commit)
from c8e97077314e1983b4e3e962da366947a8c9ab61 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a505f3f05dab1582d9a09fccc1855587044eb72
commit 0a505f3f05dab1582d9a09fccc1855587044eb72
Merge: c8e9707 15754a5
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 15:29:48 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 15:29:48 2012 -0500
Merge topic 'update-KWIML' into next
15754a5 KWIML: Fix test_INT_format typo
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15754a55688b1f51dd0200551a84c772ce598f39
commit 15754a55688b1f51dd0200551a84c772ce598f39
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 15:27:35 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Mar 9 15:27:35 2012 -0500
KWIML: Fix test_INT_format typo
Do not print @KWIML@_INT_ twice.
diff --git a/Utilities/KWIML/test/test_INT_format.h.in
b/Utilities/KWIML/test/test_INT_format.h.in
index feca446..a8ea263 100644
--- a/Utilities/KWIML/test/test_INT_format.h.in
+++ b/Utilities/KWIML/test/test_INT_format.h.in
@@ -24,7 +24,7 @@
{ \
T const x = VALUE(T, U); \
T y = C(V); \
- printf(LANG @KWIML@_INT_ #C : \
+ printf(LANG #C :\
expression [%@KWIML@_INT_PRI##PRI], \
literal [%@KWIML@_INT_PRI##PRI], x, y); \
if(x == y)\
---
Summary of changes:
Utilities/KWIML/test/test_INT_format.h.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3148-gab8fc0f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ab8fc0f1e52eb47d7d1443e2ca2bed9e01daa61c (commit)
via 289e5e6012053a356d6a7b9a9351c4b4127a50d9 (commit)
via f94ae0ecdac2fd8e8d68dde7dd16550bdee0493d (commit)
from 0a505f3f05dab1582d9a09fccc1855587044eb72 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab8fc0f1e52eb47d7d1443e2ca2bed9e01daa61c
commit ab8fc0f1e52eb47d7d1443e2ca2bed9e01daa61c
Merge: 0a505f3 289e5e6
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 15:30:17 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 9 15:30:17 2012 -0500
Merge topic 'update-KWIML' into next
289e5e6 Merge branch 'upstream-kwiml' into update-KWIML
f94ae0e KWIML: Make test_INT robust to #define-d int#_t and INT#_C
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=289e5e6012053a356d6a7b9a9351c4b4127a50d9
commit 289e5e6012053a356d6a7b9a9351c4b4127a50d9
Merge: 285f0db f94ae0e
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Mar 9 15:28:40 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Mar 9 15:28:40 2012 -0500
Merge branch 'upstream-kwiml' into update-KWIML
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f94ae0ecdac2fd8e8d68dde7dd16550bdee0493d
commit f94ae0ecdac2fd8e8d68dde7dd16550bdee0493d
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Mar 7 16:05:17 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Mar 9 15:26:26 2012 -0500
KWIML: Make test_INT robust to #define-d int#_t and INT#_C
Our TEST* macro calls pass arguments such as int64_t with the
expectation that the preprocessing token will be used literally.
Some platforms #define int64_t as long long which is not a valid
preprocessing token. Perform preprocessor symbol concatenation
on the type names at the first level of macro evaluation to avoid
expanding the names.
diff --git a/test/test_INT_format.h.in b/test/test_INT_format.h.in
index 72a62f2..a8ea263 100644
--- a/test/test_INT_format.h.in
+++ b/test/test_INT_format.h.in
@@ -18,15 +18,13 @@
# define LANG C
#endif
-#define VALUE(T, U) \
-(@KWIML@_INT_##T)((@KWIML@_INT_##U)0xab \
-((sizeof(@KWIML@_INT_##T)-1)3)) \
+#define VALUE(T, U) (T)((U)0xab ((sizeof(T)-1)3))
-#define TEST_C(C, V, PRI, T, U) \
+#define TEST_C_(C, V, PRI, T, U)\
{ \
- @KWIML@_INT_##T const x = VALUE(T, U);\
- @KWIML@_INT_##T y = @KWIML@_INT_##C(V); \
- printf(LANG @KWIML@_INT_ #C : \
+ T const x = VALUE(T, U); \
+ T y = C(V); \
+ printf(LANG #C :\
expression [%@KWIML@_INT_PRI##PRI], \
literal [%@KWIML@_INT_PRI##PRI], x, y); \
if(x == y)\
@@ -40,9 +38,9 @@
} \
}
-#define TEST_PRI(PRI, T, U, STR)\
+#define TEST_PRI_(PRI, T, U, STR) \
{ \
- @KWIML@_INT_##T const x = VALUE(T, U);\
+ T const x = VALUE(T, U); \
char const* str = STR;\
sprintf(buf, %@KWIML@_INT_PRI##PRI, x); \
printf(LANG @KWIML@_INT_PRI #PRI :\
@@ -58,11 +56,11 @@
} \
}
-#define TEST_SCN(SCN, T, U, STR) TEST_SCN2(SCN, SCN, T, U, STR)
-#define TEST_SCN2(PRI, SCN, T, U, STR) \
+#define TEST_SCN_(SCN, T, U, STR) TEST_SCN2_(SCN, SCN, T, U, STR)
+#define TEST_SCN2_(PRI, SCN, T, U, STR) \
{ \
- @KWIML@_INT_##T const x = VALUE(T, U);\
- @KWIML@_INT_##T y;
[Cmake-commits] CMake branch, master, updated. v2.8.7-635-g71c16e4
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 71c16e457c795bc6635515f026c5f9f8d952b59d (commit) from c7bdef5b48fe74f92d75f538e702257e7de1a998 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=71c16e457c795bc6635515f026c5f9f8d952b59d commit 71c16e457c795bc6635515f026c5f9f8d952b59d Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Mar 10 00:01:03 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Mar 10 00:05:06 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index b00f782..a0694e8 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 03) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 09) +SET(KWSYS_DATE_STAMP_DAY 10) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
