Hi,
In a private mailing with Dave Abrahams and Brad King I wrote a
proposal of how I imagine PCH support should be implemented. Brad
asked me to send it to this list for further discussion.
Please note that even though I use present tense in the proposal,
nothing descibed below is implemented
Now that the ninja generator is on by default on windows, it is not
building on the old compilers. Looks like it is missing a std:: on a
make_pair call.
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13303
==
Reported By:tree
Assigned To:
On 14.06.2012 17:05, Bill Hoffman wrote:
Now that the ninja generator is on by default on windows, it is not
building on the old compilers. Looks like it is missing a std:: on a
make_pair call.
I'll have a look at it. (I'm also busy fixing the broken Linux tests since my
last commit)
2012/6/14 David Cole david.c...@kitware.com:
Sounds awesome to me!
When can you submit a patch? :-)
Thanks for the motivation! While I would like to contribute a patch, I
have absolutely no idea where to start.
Should it go to cmAddExecutableCommand.cxx and
cmAddLibraryCommand.cxx? Or rather
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13304
==
Reported By:Shawn Adams
Assigned To:
I've got a fix locally in the ninja normal target generator:
std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
locGtor-AddArchitectureFlags(flags,
On 14.06.2012 19:43, David Cole wrote:
I've got a fix locally in the ninja normal target generator:
std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
The Continuous dashboards check 'next' -- the Nightly dashboards snap to
'nightly' which is a snapshot of 'next' created at the nightly start time
each night...
So, after a merge to 'next' on the stage, the dashboards will pick up those
changes next time they run.
On Thu, Jun 14, 2012 at 2:39
OK -- I merged the change to next at the tip of the stage/ninja-cldeps
branch:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=555bda4e436435c37690aa5f31f4d254793d5b4e
On Thu, Jun 14, 2012 at 3:17 PM, David Cole david.c...@kitware.com wrote:
The Continuous dashboards check 'next' -- the
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13306
==
Reported By:Jona
Assigned To:
Hi,
we hit an issue in KDE related to the usage (or not-usage) of the
OBJECT_DEPENDS source file property.
In KDEs FindQt4.cmake the macro
qt4_generate_moc(inCppFile outMocFile)
uses the OBJECT_DEPENDS property to enforce that the moc file is generated
before the cpp file is built.
This seems
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13307
==
Reported By:Javier
Assigned To:
I found a new problem were I could not
find a good solution:
cmd.exe /c $PRE_LINK
cmake.exe -E vs_link_dll $in
$POST_LINK
Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
and could be dropped, but this is wrong.
Is
On 15.06.2012 00:33, Peter Kümmel wrote:
I found a new problem were I could not
find a good solution:
cmd.exe /c $PRE_LINK
cmake.exe -E vs_link_dll $in
$POST_LINK
Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
15 matches
Mail list logo