Hello List,
I've taken an interested in D lately and in order to play around
there, of course I want CMake. There was an effort in 2007 to support
D, since abandoned, but I'm trying to take up the cause.
The project is just getting off the ground here:
http://code.google.com/p/cmaked2/source/chec
Yes, this patch fixes the problem thank you.
On Fri, Aug 13, 2010 at 1:39 PM, Brad King 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.
>> Makefile:118: ***
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 spe
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" unti
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 kder
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 wrote:
> On Fri, Aug 13, 2010 at 11:50 AM, Brad King wrote:
>> On 08/13/2010 02:45 PM, J Decker wrote:
>>> On Fri, Aug
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}" ${MAKE_TOKENIZE
On Fri, Aug 13, 2010 at 11:50 AM, Brad King wrote:
> On 08/13/2010 02:45 PM, J Decker wrote:
>> On Fri, Aug 13, 2010 at 11:24 AM, Brad King 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.
>>
On 13.08.2010, at 18:33, Chris Wolf 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
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, but
On 08/13/2010 02:45 PM, J Decker wrote:
> On Fri, Aug 13, 2010 at 11:24 AM, Brad King 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
On Fri, Aug 13, 2010 at 11:24 AM, Brad King 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 - it's only wind
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 "C
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
>>
the name of the directory does not matter... I was using an entirely
different name.
On Thu, Aug 12, 2010 at 8:21 PM, Alan W. Irwin
wrote:
> On 2010-08-12 17:36-0700 J Decker wrote:
>
>> To Reiterate steps
>>
>> --
>>
>> mkdir /test
>> touch /test/CMakeLists.txt
>> mkdir /build
>> cd
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 \
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BO
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 R
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:
http://
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
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 th
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":
> ht
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
li
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 spea
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 d
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 describe
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
26 matches
Mail list logo
