On 09/20/2014 12:09 PM, Mourad Boufarguine wrote:
> On 09/19/2014 10:28 AM, Brad King wrote:
>> Interesting. I started with an IDE-generated project file to
>> see what the generator needs to produce. What version of
>> Nsight Tegra are you using?
>
> I'm using Nsight Tegra 1.6.
I used 1.5.1 ori
Hi Christopher,
We added the support for shaders but have only added the basic support to
include shaders. Let me check what can be done to add the other properties.
Gilles Khouzam
Senior Development Lead
Microsoft OSG
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behal
On Wed, Sep 24, 2014 at 3:55 PM, Brad King wrote:
> On 09/22/2014 07:15 PM, Aleix Pol wrote:
> > {
> > version: "1.0",
> > targets: [...]
> > }
>
> Yes. The version number could either be maintained as its own
> thing, or just the CMake version number could be used. Either way
> the Help/variab
On 09/24/2014 10:49 AM, Adam Strzelecki wrote:
> do implicit push&pop for include when CMP0011 is NEW *OR*
> when included module is part of CMake own modules
I think this would be okay, as long as NO_POLICY_SCOPE
is still honored when given explicitly to include() and
find_package(). The only re
On 09/24/2014 10:47 AM, Adam Strzelecki wrote:
> Are subprocess allowed then?
>
>> (…) just to filter our own output.
>
> Please note that such solution that filters stdout low level
Yes, but I do not think we should have to do any filtering
at all. The output should just be written to match wh
Again, shouldn't we consider having CMP0011 always NEW for internal modules /
or do implicit push&pop for include when CMP0011 is NEW *OR* when included
module is part of CMake own modules?
--Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://
> We will *NOT* be introducing use of *THREADS* in CMake just
> to filter our own output.
Yeah, got it. Are subprocess allowed then?
> (…) just to filter our own output.
Please note that such solution that filters stdout low level is superior to
doing it as CMake owns level because cmake may be
On 09/24/2014 10:29 AM, Adam Strzelecki wrote:
> Please try to build this stage branch and try to run cmake
In case I was not clear the last two times:
We will *NOT* be introducing use of *THREADS* in CMake just
to filter our own output.
-Brad
--
Powered by www.kitware.com
Please keep messag
> What happens if something else occurs in between that prints
> a message?
That's why my solution is completely automatic, does not require any changes in
existing modules, and it works as desired so only:
-- Doing something
-- Doing something - Result
That arrive to stdout are compacted
Okay I have just merged into next a topic that switches over the
official release to be built with UDBZ.
Once the dashboards are happy I will update the x86_64 release to not
be universal binaries.
On Wed, Sep 24, 2014 at 10:15 AM, Brad King wrote:
> On 09/24/2014 10:07 AM, Robert Maynard wrote:
On 09/24/2014 10:07 AM, Robert Maynard wrote:
> I believe that the reason for both of these behaviors is that the
> DragNDrop generator was written when a significant number of < 10.6
> machines existed in the wild.
>
> I don't see any reason why we shouldn't update the default for
> CPACK_DMG_FOR
On 09/22/2014 10:07 AM, Brad King wrote:
> Or, one could add the explicit PUSH/POP in modules, e.g.
>
> cmake_policy(PUSH)
> cmake_policy(SET CMP0054 NEW)
> ... module code ...
> cmake_policy(POP)
Until such time as someone wishes to port a module explicitly
with the above approach we can use
>
> What happens if something else occurs in between that prints
> a message? Do we tolerate
>
> -- Doing something-- Unrelated Message
> - Result
>
> instead of
>
> -- Doing something
> -- Unrelated Message
> -- Doing something - Result
>
Sure, why not? There's no requirement to use the NO
I believe that the reason for both of these behaviors is that the
DragNDrop generator was written when a significant number of < 10.6
machines existed in the wild.
I don't see any reason why we shouldn't update the default for
CPACK_DMG_FORMAT to be UDBZ instead of UDZO
On Wed, Sep 24, 2014 at 8:
On 09/22/2014 07:15 PM, Aleix Pol wrote:
> {
> version: "1.0",
> targets: [...]
> }
Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the
On 09/24/2014 09:44 AM, Chuck Atkins wrote:
> message(STATUS "Doing something" NOENDL)
> # Do some stuff
> message(STATUS " - Result")
What happens if something else occurs in between that prints
a message? Do we tolerate
-- Doing something-- Unrelated Message
- Result
instead of
-- Doing s
I like the idea of reducing the extra-verbose output, and maybe I'm missing
something here but could this possibly be done with a much simpler
approach? It seems the way these double messages happen is with the
following CMake code:
message(STATUS "Doing something")
# Do some stuff
message(STATUS
On 09/24/2014 08:02 AM, Adam Strzelecki wrote:
> cmThread utility class
Introducing threads is exactly the "too much infrastructure"
to which I was referring in my previous response. I'm sorry
to reject all the effort you put into the threads approach so
far, but I did say this earlier.
> cmake
I've been playing with the Windows shader options. I can see that it's now
possible to set the following:
set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel)
set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex)
Which is cool, but I can't see if there's a
Not an big issue but official DMG bundles are 40 MB where my manually built one
is 21 MB (half of it).
So any reason for:
* providing universal FAT binaries instead of 64-bit only for >=10.6 Darwin64
build, as anyway there is 32-bit build for these who have 32-bit only CPU?
* using DMG zlib comp
FYI stage/compact-status-log was updated with more elegant C++ implementation
introducing new cmStdoutFilter & cmThread utility classes enabled when certain
headers are present in the system, so in cmakemain.cxx we simply put:
cmStdoutFilter stdoutFilter("-- ");
--Adam
--
Powered by www.ki
Hi,
I would like to use kconfig from Linux for my project settings.
So I integrate fixdep tools into CMake for parsing CONFIG_xxx key words
and set proper dependency of files that are generated by kconfig.
My scratch is attached.
However, here come some issues.
1. The codes from fixdep is declare
VERBOSE=1 only triggers the first level to be verbose in a make... any
subsequent call to wmake passes '-s' option and not VERBOSE=1
continuously...
I'm not sure where the '-s' option on wmake is coming from, browsed the
code a little... but it'd be kind of nice if this feature worked.
--
Powere
23 matches
Mail list logo
