Hi Jeremy.
Does ${BUILD_BIN} perhaps start with a slash? If so, it would be
interpreted as an absolute path, which of course ignores
CMAKE_INSTALL_PREFIX.
Petr
On Wed, Sep 24, 2014 at 7:58 AM, Jeremy Ardley jeremy.ard...@gmail.com
wrote:
I am using cmake 2.8.9 on debian wheezy. I'm fairly
I don't know why @ was inserted, but here's why it overrides the absolute
path: because it has no special meaning. The path then becomes @/sbin,
which is not an absolute path (doesn't start with '/'), so the install
prefix is prepended normally. Bear in mind that Unix directory and file
names can
Thanks for assistance. I forgot 'reply all'. Will be better next time :-)
On 24/09/14 14:58, Petr Kmoch wrote:
I don't know why @ was inserted, but here's why it overrides the
absolute path: because it has no special meaning. The path then
becomes @/sbin, which is not an absolute path (doesn't
On 24.09.2014 02:40, jmerkow wrote:
It seems the best way to do this would be to override the template with a
number of configurable entries?
So I could add something like (there's about 15 of em):
Registry Id='regid7' Root='HKLM' Key='Software\@proj_name@\@proj_name@
@proj_FULL_VERSION@'
I am already using /MP and the equivalent to the /maxcpucount. It is the
/MP one that is important in this context as I am only concerned with
improving the speed of a single project out of the many in my solution. I
believe the problem is with cmake rather than with Visual Studio as I can
Hendrik Sattler post@... writes:
On 23. September 2014 16:22:40 MESZ, Cristian Adam
QCC compiler generates for this project dependency files which look
like:
c:\projects\my_proj\include\/a.h \
c:\projects\my_proj\src\/a.cpp \
c:\projects\my_proj\other\..\/include/b.h \
/MP flag is specifically for compiling object files in parallel so it
won't cause multiple custom commands to be run in parallel as each one
is a msbuild custom build item task. I don't know exactly how msbuild
treats custom tasks such as these, but they might be implicitly
serial.
On Wed, Sep
Ok, I have no idea what's going on.
I'm using configure_file to put the get_preresiquites cmake script in the
binary dir...
It's running...
It's not show any errors...
It's also not finding any dependencies...
I've double and triple checked that the variable I'm using in the message
command is
If you send some code, maybe somebody can spot something wrong with the code...
On Wed, Sep 24, 2014 at 9:57 AM, Richard Shaw hobbes1...@gmail.com wrote:
Ok, I have no idea what's going on.
I'm using configure_file to put the get_preresiquites cmake script in the
binary dir...
It's
Ok I'm going the fragment injection route, but having some issues.
So I found the component id for the target that these registry values will
be needed by in files.wxs:
Component Id=CMP_ID_1 Guid=*
File Id=FILE_ID_1 Source=C:/blah/blah/Bin/myapp.exe KeyPath=yes/
/Component
In this case its
On 24.09.2014 21:26, jmerkow wrote:
Am I obtaining the id wrong? The documentation is a little confusing
compared to whats being generated. so I'm not sure exactly sure if I have
the proper id. Is there a way to get the Id from the in cmake to configure
the file directly? Maybe there is another
I figured it out...
I'm cross-compiling MinGW on Fedora linux and it just dawned on me that the
cmake instance run by CPack probably isn't using the correct environment. I
think it would be best if this was handled automatically but for the time
being I pushed the required variables into the
Ok, I've double checked everything and I'm not sure whats going on.
I was looking in files.wxs (in _CPack_Packages/win64/WIX) for the component
ID, and i've tried a few different ones. I also dropped the config file
step and used your example patch.xml:
CPackWiXPatch
CPackWiXFragment
I forgot to mention that I double checked that this particular code was being
executed. I started changing the name (and adding a time stamp) to the msi
in the same section of code to double check. Here is it is (its at send of
my code for cpack):
...
if(WIN32)
if(MSVC)
On 24.09.2014 23:20, jmerkow wrote:
Ok, I've double checked everything and I'm not sure whats going on.
I was looking in files.wxs (in _CPack_Packages/win64/WIX) for the component
ID, and i've tried a few different ones. I also dropped the config file
step and used your example patch.xml:
Hi all,
I would like to use CONFIGURE_PACKAGE_CONFIG_FILE() [1] instead of
CONFIGURE_FILE() for my export configurations. Unfortunately, it seems
that CONFIGURE_PACKAGE_CONFIG_FILE() only supports the @ONLY syntax. I
do use nested variables names in the export configuration, though,
e.g.,
```
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.
--
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
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
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
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 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 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
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
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
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 NOENDL, it
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 the
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_FORMAT to
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
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
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
Again, shouldn't we consider having CMP0011 always NEW for internal modules /
or do implicit pushpop 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:
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 what
we
On 09/24/2014 10:49 AM, Adam Strzelecki wrote:
do implicit pushpop 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
On Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com 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
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
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 originally.
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 efd16ba928476bc1a576efc16d61d31f0f49 (commit)
via
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 be5215c4ba85942a22143894048a4f160b65a87a (commit)
via
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 e6a7abd2b69b45933abb5617a8bf5b800b2dde6f (commit)
via
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 17a457dcb02e351efe5d1dd093c9443ba206667a (commit)
via
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 da8aa48b29761f697f23995b31eeb3d6179b11c3 (commit)
via
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 2040bb2a6f3ab2121af8b04dbc49b460384b6acd (commit)
via
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 2dbe24798a0a72535485ca08a6a1f52835baab7a (commit)
via
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 2f91e810f7defe668176c9e57971e16ffc610f6e (commit)
via
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 d32009a23a164d10e49b8f3e9508ec7c60b3fe88 (commit)
via
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 c2768d6897864156f644c35caf332c945ff19685 (commit)
via
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 2ee6f7d43da4c5a3d466915f81c9775feb2c777e (commit)
via
20140924)
+set(CMake_VERSION_PATCH 20140925)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
49 matches
Mail list logo
