Hi!
During my migration from qmake to cmake it is pure hell for me to support the
multi configuration visual studio solutions, especially for some parts like the
installation steps, custom targets and so on. Most of them are because of the
problem with the different build dirs in this multi
Hello,
I need to execute following command with add_custom_command:
*python test.py src dst*
The first argument is empty. Sometimes it may have some text. So Python
process the args as [test.py, , src, dst]. But when I do the same with
add_custom_command, the empty argument is not
ya, ignore the other types, and just set CMAKE_BUILD_TYPE appropriratly.
On Mon, Jun 30, 2014 at 12:43 AM, Jörg Kreuzberger
j.kreuzber...@procitec.de wrote:
Hi!
During my migration from qmake to cmake it is pure hell for me to support
the multi configuration visual studio solutions,
On 06/30/2014 09:42 AM, abid rahman wrote:
Hello,
I need to execute following command with add_custom_command:
*python test.py src dst*
The first argument is empty. Sometimes it may have some text. So Python
process the args as [test.py, , src, dst]. But when I do the same with
I thought the CMAKE_BUILD_TYPE only would work for nmake makefile generation
(Single Configuration Generator) and is ignored in Visual Studio SLN Generator
(Multi Configuration Generator).
Maybe i should clear or reduce the list of CMAKE_CONFIGURATION_TYPES to just
one?
-Ursprüngliche
On Mon, Jun 30, 2014 at 1:13 AM, Jörg Kreuzberger j.kreuzber...@procitec.de
wrote:
I thought the CMAKE_BUILD_TYPE only would work for nmake makefile
generation (Single Configuration Generator) and is ignored in Visual Studio
SLN Generator (Multi Configuration Generator).
Maybe i should
You can set CMAKE_CONFIGURATION_TYPES to your own list of
configurations (including limiting it to a single configuration) as
long as you set it *before* the project command in your CMakeLists.txt
file. This technique works with the Visual Studio and Xcode generators.
See the following bug
Thank you Nils, VERBATIM really worked for me as shown below:
*add_custom_command(*
*OUTPUT ${some_files}*
*COMMAND ${PYTHON_EXECUTABLE} test.py ${src} ${dst} *
*DEPENDS ${... all deps ..}*
*VERBATIM )*
But now got a new question. I tried setting a variable and
I think it should work if you put quotes around the expansion - otherwise,
an empty variable expands to nothing, not to an empty string:
*add_custom_command(*
*OUTPUT ${some_files}*
*COMMAND ${PYTHON_EXECUTABLE} test.py ${prefix} ${src} ${dst}*
*DEPENDS ${... all deps ..}
OK, I think It is better to stick to my first option. That looks better.
Thank you for all your suggestions.
Abid K.
On Mon, Jun 30, 2014 at 4:56 PM, Jakub Zakrzewski jzakrzew...@e2e.ch
wrote:
That's because now you've set prefix to empty string and it'll be
expanded to nothing. VERBATIM
That's because now you've set prefix to empty string and it'll be expanded to
nothing. VERBATIM made the empty quotes appear because they were put directly
as parameter.
I think if you set(prefix \\) it'll do the trick.
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of abid rahman
On Mon, Jun 30, 2014 at 3:09 AM, David Cole dlrd...@aol.com wrote:
You can set CMAKE_CONFIGURATION_TYPES to your own list of configurations
(including limiting it to a single configuration) as long as you set it
*before* the project command in your CMakeLists.txt file. This technique
works
I need to copy resource files from the source directory to the binary
directory with the creation of my executable. I want CMake's
dependency tracking to handle (re)copying these files whenever the
source has been touched.
Looking at other similar questions like:
Hi Eric.
It seems to me that you're copying from source dir to binary dir, but all
dependencies are on the source dir file only. Therefore, there is nothing
to trigger the generation of the binary-dir file. Perhaps you wanted
'fooresources' to depend on the binary-dir file instead?
Petr
On
Thanks for the reply. So the usage case is that people are going to be
modifying the resources in the source directory. (These changes have
to be checked into revision control.) So I'm having trouble seeing how
depending on the binary directory is going to work. (The reason I must
copy the
Hi all,
I am getting download error on firefox, chrome and from terminal using wget
wget http://www.cmake.org/files/v3.0/cmake-3.0.0.tar.gz
--2014-06-30 16:13:32-- http://www.cmake.org/files/v3.0/cmake-3.0.0.tar.gz
Proxy request sent, awaiting response... 200 OK
Length: 5489804 (5.2M)
On 06/30/2014 04:19 PM, Rashad M wrote:
Hi all,
I am getting download error on firefox, chrome and from terminal using wget
wget http://www.cmake.org/files/v3.0/cmake-3.0.0.tar.gz
--2014-06-30 16:13:32-- http://www.cmake.org/files/v3.0/cmake-3.0.0.tar.gz
Proxy request sent, awaiting
Okay, I switched just the add_custom_target DEPENDS to the binary
directory (but left the add_custom_command alone). That seems to be
doing what I need. I think I'm still not fully understanding the
reasoning behind it, but problem solved I guess.
Thanks,
Eric
On 6/30/14, Eric Wing
The reasoning is this: when a target is about to be built, it checks its
dependencies and if any are out of date (or don't exist), it triggers their
building. The binary-dir file is built by the custom command. So when the
custom target is built, it will check its dependency (the binary-dir file)
I am behind a proxy. Is that the problem?
I tried .Z, .tar.gz, .zip files directly from browser and also using wget
On Mon, Jun 30, 2014 at 4:24 PM, Nils Gladitz nilsglad...@gmail.com wrote:
On 06/30/2014 04:19 PM, Rashad M wrote:
Hi all,
I am getting download error on firefox, chrome and
On 06/30/2014 04:39 PM, Rashad M wrote:
I am behind a proxy. Is that the problem?
I tried .Z, .tar.gz, .zip files directly from browser and also using wget
The proxy may be the problem since with it you are not directly
downloading from cmake.org but rather from the proxy which itself would
Ok. I will clone via github and switch to release branch. I can download
other tar files behind the same proxy. Download is also not blocked here,
at the end of download it says failed.
On Mon, Jun 30, 2014 at 4:49 PM, Nils Gladitz nilsglad...@gmail.com wrote:
On 06/30/2014 04:39 PM, Rashad M
Stephen Kelly wrote:
If you build a library using foo.cpp it will contain the glVertex2i
symbol even though its headers wont include it. Likewise a consumer of
that library does not need to have the headers,
but will need to link against a library containing the symbol.
Ah, I guess we're
Hello,
QtSQL provides abstracted access to database data. It does not depend on
QtGui or QtWidgets.
It also provides the header-only qsqlrelationaldelegate.h. The contents of
that header depend on QtWidgets, and are wrapped in an ifdef QT_WIDGETS_LIB.
That means that the
2014-06-30 10:18 GMT+02:00 Stephen Kelly steve...@gmail.com:
Hello,
QtSQL provides abstracted access to database data. It does not depend on
QtGui or QtWidgets.
It also provides the header-only qsqlrelationaldelegate.h. The contents of
that header depend on QtWidgets, and are wrapped in
On 06/27/2014 04:13 PM, Adam Strzelecki wrote:
Previously all explicit dependencies inside build folder were considered as
possible build command side-effects and phony rules were produced for them in
case they don't exist yet starting build. This however incorrect since regular
compile inputs
On 06/27/2014 04:32 PM, Adam Strzelecki wrote:
As you probably notice percentage is decoupled by rest of status line.
This was reported here:
http://www.cmake.org/Bug/view.php?id=12991
but it hasn't bothered anyone enough to fix it.
-Brad
--
Powered by www.kitware.com
Please keep messages
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 84fdacd2a8e2e32fffcc8762f7bf6804d5a4b4a0 (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 969bf35da76bc919539ce3792a0c421af7059546 (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 2d24d4c8a44681b4705bd598615de6ca22265d5f (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 19fa615dde14d564b9e67d9066d1fa606d26e4c5 (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 a1fd40176eb1868b7c098b0fa64b13f89263d6fd (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 7448cd558c0aafcde567124b52f545d28f838543 (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 f09755c6254bcd19da2a429ea9b9bb4283d26018 (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 1a575a91d22d5ae5f3b8f73ad67f478ece3f9565 (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 2e8a5ac31f3f95cd01cfde4f86dc78d091b13d7e (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 4f7f6651830b847de006bf8bdc5cbd4a9e39805f (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 1563668fd0020ee1e2a59b97827468777e3b7955 (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 2f8fa2dc6c36f450c6d74be64735abca32214387 (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 724348323c1b882f127d90df0714faedc6461804 (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 4c5d48a66f93d79cb3866eb19b72a06346d64ed0 (commit)
via
41 matches
Mail list logo
