On 08/13/2010 11:57 AM, Eric Noulard wrote:
Please push to github first and send me a pointer. I'll fetch
it and test on Windows and Cygwin for you.
here you go:
http://github.com/TheErk/CMake/tree/libarchive-wrapper
That builds on Cygwin and on Windows with MS and GNU tools.
Please
On 12. Aug, 2010, at 22:37 , Chris Wolf wrote:
I have a project which creates a shared library and a utility which uses this
shared library. I would like to be able to run the utility within the build
tree and also from the final install directory. I can do this, it works,
but the path
On 12. Aug, 2010, at 22:41 , Carlos Gonçalves wrote:
Hi,
On 2010/08/12, at 20:15, Chris Wolf wrote:
On 8/12/10 10:20 AM, Carlos Gonçalves wrote:
Hi,
I have already looked everywhere possible (so to speak) on how to create a
Framework + Unix tools as described in [1] but found no
On 8/13/10 3:47 AM, Michael Wild wrote:
On 12. Aug, 2010, at 22:37 , Chris Wolf wrote:
I have a project which creates a shared library and a utility which uses this
shared library. I would like to be able to run the utility within the build
tree and also from the final install
On 2010/08/13, at 08:52, Michael Wild wrote:
On 12. Aug, 2010, at 22:41 , Carlos Gonçalves wrote:
Hi,
On 2010/08/12, at 20:15, Chris Wolf wrote:
On 8/12/10 10:20 AM, Carlos Gonçalves wrote:
Hi,
I have already looked everywhere possible (so to speak) on how to create a
I have confirmed that the RPATH handling, as documented here:
http://www.cmake.org/Wiki/CMake_RPATH_handling
Is only accurate for the Linux case and *NOT* for MacOS.
Here is the summary of my findings:
Default RPATH:
http://www.cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings
On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
I have confirmed that the RPATH handling, as documented here:
http://www.cmake.org/Wiki/CMake_RPATH_handling
Is only accurate for the Linux case and *NOT* for MacOS.
Here is the summary of my findings:
Default RPATH:
On 8/13/10 9:29 AM, Michael Wild wrote:
On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
I have confirmed that the RPATH handling, as documented here:
http://www.cmake.org/Wiki/CMake_RPATH_handling
Is only accurate for the Linux case and *NOT* for MacOS.
Here is the summary of my
On 8/13/10 10:23 AM, Chris Wolf wrote:
On 8/13/10 9:29 AM, Michael Wild wrote:
On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
I have confirmed that the RPATH handling, as documented here:
http://www.cmake.org/Wiki/CMake_RPATH_handling
Is only accurate for the Linux case and *NOT*
On 13. Aug, 2010, at 16:32 , Chris Wolf wrote:
On 8/13/10 10:23 AM, Chris Wolf wrote:
On 8/13/10 9:29 AM, Michael Wild wrote:
On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
I have confirmed that the RPATH handling, as documented here:
On 8/13/10 11:21 AM, Michael Wild wrote:
On 13. Aug, 2010, at 16:32 , Chris Wolf wrote:
On 8/13/10 10:23 AM, Chris Wolf wrote:
On 8/13/10 9:29 AM, Michael Wild wrote:
On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
I have confirmed that the RPATH handling, as documented here:
Chris Wolf wrote:
[]
Have you actually built shared libraries on MacOS with CMake? If so, maybe an
example
of yours would be more helpful.
The following settings work for me when building vtk5.6 for Fink:
-DCMAKE_INSTALL_NAME_DIR:STRING=/sw/lib/vtk56 \
On 08/11/2010 07:04 PM, Andreas Pakulat wrote:
On 11.08.10 16:07:21, Brad King wrote:
This is what causes the header to be generated before dependencies
are scanned (as you observed in the quote above). I do not think
anything in the kdereviewboard target can compile before the above
steps
On 8/12/2010 8:36 PM, J Decker wrote:
cmake -G MinGW Makefiles /test
The path /test is not a valid full path on windows.
That syntax is used by many tools for command line options.
If I use a backslash instead:
cmake -G MinGW Makefiles \test
I get
CMake Error: The source directory
On Fri, Aug 13, 2010 at 11:24 AM, Brad King brad.k...@kitware.com wrote:
On 8/12/2010 8:36 PM, J Decker wrote:
cmake -G MinGW Makefiles /test
The path /test is not a valid full path on windows.
yes it is. and the forward slash or backslash is handled perfectly by
all windows internals -
On 08/13/2010 02:45 PM, J Decker wrote:
On Fri, Aug 13, 2010 at 11:24 AM, Brad King brad.k...@kitware.com wrote:
On 8/12/2010 8:36 PM, J Decker wrote:
cmake -G MinGW Makefiles /test
The path /test is not a valid full path on windows.
yes it is. and the forward slash or backslash is
Does anybody have an example where they use CMake (and probably a
little C code) to generate a file with a timestamp for the beginning
and/or end of the build in a cross-platform manner? I know CMake
can't do this itself if you assume only the Makefiles/Visual Studio
build logic at build time,
On 13.08.2010, at 18:33, Chris Wolf cw10...@gmail.com wrote:
On 8/13/10 11:21 AM, Michael Wild wrote:
On 13. Aug, 2010, at 16:32 , Chris Wolf wrote:
On 8/13/10 10:23 AM, Chris Wolf wrote:
On 8/13/10 9:29 AM, Michael Wild wrote:
On 13. Aug, 2010, at 15:25 , Chris Wolf
On Fri, Aug 13, 2010 at 11:50 AM, Brad King brad.k...@kitware.com wrote:
On 08/13/2010 02:45 PM, J Decker wrote:
On Fri, Aug 13, 2010 at 11:24 AM, Brad King brad.k...@kitware.com wrote:
On 8/12/2010 8:36 PM, J Decker wrote:
cmake -G MinGW Makefiles /test
The path /test is not a valid full
Hi,
I am new to using cmake, and trying to get a custom build command to embed
quotes for a project that I'm compiling in MS visual studio on a windows
machine.
I have this in my cmake file:
COMMAND ${FLEX_EXECUTABLE} -t ${WEBCORE_DIR}/css/tokenizer.flex |
${PERL_EXECUTABLE}
But actually it needs to not prepend anything if it starts with a
slash, otherwise you couldn't build from a network share by name
On Fri, Aug 13, 2010 at 12:25 PM, J Decker d3c...@gmail.com wrote:
On Fri, Aug 13, 2010 at 11:50 AM, Brad King brad.k...@kitware.com wrote:
On 08/13/2010 02:45
On 13.08.10 14:09:21, Brad King wrote:
On 08/11/2010 07:04 PM, Andreas Pakulat wrote:
On 11.08.10 16:07:21, Brad King wrote:
This is what causes the header to be generated before dependencies
are scanned (as you observed in the quote above). I do not think
anything in the kdereviewboard
On 8/12/2010 8:36 PM, J Decker wrote:
CMake Error: The source directory C:/build/test does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Makefile:118: *** [cmake_check_build_system] Error 1
I found it. CMake actually is preserving the path as /test until
the
On 2010/08/13, at 08:52, Michael Wild wrote:
On 12. Aug, 2010, at 22:41 , Carlos Gonçalves wrote:
Hi,
On 2010/08/12, at 20:15, Chris Wolf wrote:
On 8/12/10 10:20 AM, Carlos Gonçalves wrote:
Hi,
I have already looked everywhere possible (so to speak) on how to create a
Yes, this patch fixes the problem thank you.
On Fri, Aug 13, 2010 at 1:39 PM, Brad King brad.k...@kitware.com wrote:
On 8/12/2010 8:36 PM, J Decker wrote:
CMake Error: The source directory C:/build/test does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
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 2d8fd35699b05a4805b2b27447be38ebac317409 (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 a2dcdb800f82689ff4ceb8f195f75fcb5d2dcba9 (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 16168ab0c3549b6953fe95354446508ce3cc945e (commit)
from
28 matches
Mail list logo
