On 2. Jun, 2010, at 5:44 , Michael Hertling wrote:
> On 06/02/2010 04:24 AM, Clark Gaebel wrote:
>> I have a massive .cpp file that has been autogenerated ahead of time.
>> However, whenever I build it, according to gcc timing information, it
>> spends all its time in "variable tracking". Therefo
Den 01-06-2010 18:00, Schnurlinger Burli skrev:
(2)
Cmake produces a fairly usable .sln-file when I choose “Specify native
compilers” in the beginning of the CMake project generation
and let "C++" point to ( I couldn`t find any "devenv.exe" )
I don't know about the rest, but I can tell you the
On 06/02/2010 04:24 AM, Clark Gaebel wrote:
> I have a massive .cpp file that has been autogenerated ahead of time.
> However, whenever I build it, according to gcc timing information, it
> spends all its time in "variable tracking". Therefore, I would like to
> enable the flag -fno-var-tracking fo
On 06/01/2010 09:57 PM, Michael Wild wrote:
>
> On 1. Jun, 2010, at 17:02 , Hariharan wrote:
>
>> I do use ADD_CUSTOM_COMMAND to generate the files, but the actual generation
>> is done by a different Perl script. In some cases, there is no direct
>> correlation between the name of the source fil
I have a massive .cpp file that has been autogenerated ahead of time.
However, whenever I build it, according to gcc timing information, it
spends all its time in "variable tracking". Therefore, I would like to
enable the flag -fno-var-tracking for that file only (having variable
debug information
On 06/01/2010 10:34 PM, Hickel, Kelly wrote:
> I'm trying to build two different versions of a library from a single
> CMakeLists.txt file (akin to what the FAQ section 7.1 spells out for building
> shared and static libraries). However, the include_directories command
> doesn't accept a target
I'm trying to build two different versions of a library from a single
CMakeLists.txt file (akin to what the FAQ section 7.1 spells out for building
shared and static libraries). However, the include_directories command doesn't
accept a target the way that, for instance, target_link_libraries do
On Tuesday 01 June 2010, Jesper Eskilson wrote:
> On 05/31/2010 10:53 PM, Alexander Neundorf wrote:
> > On Monday 31 May 2010, Jesper Eskilson wrote:
> >> On 05/30/2010 02:13 PM, Alexander Neundorf wrote:
> >>> That's also ok.
> >>> Could you please post the output of the IAR AVR and ARM assemblers
On 1. Jun, 2010, at 17:02 , Hariharan wrote:
> I do use ADD_CUSTOM_COMMAND to generate the files, but the actual generation
> is done by a different Perl script. In some cases, there is no direct
> correlation between the name of the source file and the name of the
> destination file; and the num
On 6/1/2010 2:36 PM, Michele Caramello wrote:
I am trying to use CMake also to generate project files that can be
use plainly be used by people not having CMake installed on their
machines.
To achieve that, I though the best path would be to remove the
auto-regeneration hooks that allow the regen
Thank you for your prompt consideration!
My OS is Vista64bit, I have VC2010Express ( Version 10.0.30319.1 RTMRel) and
Windows7.1SDK installed.
"64-bit tools are not available on Visual C++ Express by default."
"To enable 64-bit tools on Visual C++ Express, install the Windows Software
Devel
On Tuesday, June 01, 2010 at 11:48 AM, Brad King wrote:
> You can delete the object file the provides the module.
>
> > Perhaps that scenario where
> > module files are deleted independent of the object/libraries is
> > artificial, but it's not really correct for the build to break if they
> > ar
I am trying to use CMake also to generate project files that can be
use plainly be used by people not having CMake installed on their
machines.
To achieve that, I though the best path would be to remove the
auto-regeneration hooks that allow the regeneration of project files
when any of the CMakeLi
On Tue, 01 Jun 2010 13:48:21 -0400, Brad King wrote:
> You can delete the object file the provides the module.
That doesn't seem to be enough if there is another target that depends
on the module. E.g. if I delete petscmat.mod and
CMakeFiles/.../petscmatmod.F.o, then run 'make all', I get an err
Jed Brown wrote:
> There is still the issue that module files don't get rebuild if they are
> deleted,
>
> make[2]: *** No rule to make target `include/petscmat.mod', needed by
> `CMakeFiles/petscdm.dir/src/dm/f90-mod/petscdmmod.F.o'. Stop.
> make[1]: *** [CMakeFiles/petscdm.dir/all] Error 2
>
On Tue, 01 Jun 2010 13:02:29 -0400, Brad King wrote:
> Jed Brown wrote:
> > Is there a way to specify where generated *.mod files will be placed?
> > Something analogous to CMAKE_LIBRARY_OUTPUT_DIRECTORY?
>
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:Fortran_MODULE_DIRECTORY
*
How can I make FindThreads.cmake find pthreads on IRIX instead of sproc?
Thanks,
Clint
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and chec
Jed Brown wrote:
> Is there a way to specify where generated *.mod files will be placed?
> Something analogous to CMAKE_LIBRARY_OUTPUT_DIRECTORY?
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:Fortran_MODULE_DIRECTORY
-Brad
___
Powered by
The only think I know is that getting Visual Studio Express 2008 to do
x64 builds involved a whole lot of hacking and such since x64 was not
officially supported by VCExpress 2008. Has this changed with VC2010
Express? It would seem that the VC 2010 Express does NOT install the
64 bit tools
Hello,
My OS is Vista64bit, I have VC2010Express ( Version 10.0.30319.1 RTMRel) and
Windows7.1SDK installed.
I have 32bit-Cmake2.8.1 installed and
http://www.cmake.org/files/v2.8/CMakeVS10FindMake.cmake is in C:\Program Files
(x86)\CMake 2.8\share\cmake-2.8\Modules
When I configure spec
On Tue, 1 Jun 2010 08:43:43 -0600, "Kelly Thompson" wrote:
> This can be done using a Fortran compile option. For gfortran, add the
> option "-M" to CMAKE_Fortran_FLAGS.
Sure, however
1. One should use -J instead because (since 4.0), "-M is deprecated to
avoid conflicts with existing GCC o
On 1. Jun, 2010, at 16:23 , Hariharan wrote:
> First off, I apologize if this is a very newbie-level question.
> I need to set the value of a variable based on based on generated files,
> using the "file" command. Something like:
> file(GLOB varFoo "*.cpp")
>
> Here the cpp files are generated,
This can be done using a Fortran compile option. For gfortran, add the
option "-M" to CMAKE_Fortran_FLAGS.
> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of
> Jed Brown
> Sent: Monday, May 31, 2010 5:41 AM
> To: cmake@cmake.org
> Subject:
First off, I apologize if this is a very newbie-level question.
I need to set the value of a variable based on based on generated files,
using the "file" command. Something like:
file(GLOB varFoo "*.cpp")
Here the cpp files are generated, so the value of varFoo comes up as empty
when the build run
On Fri, May 28, 2010 at 5:11 PM, David Cole wrote:
> CTestConfig.cmake should be downloaded from CDash and committed into your
> source tree manually before configuring and before your first dashboard
> submission.
That's what I figured, but I didn't know exactly how it fit into things.
> Why d
On 5/31/2010 4:19 AM, Sebastian Meier wrote:
Hi Bill,
Can NetBeans be driven from the command line? That is a requirement for
getting try_compile to work.
No, I don't think it is possible call NetBeans via command line in
order to build targets. But since NetBeans relies on external tool
ch
On 05/31/2010 10:53 PM, Alexander Neundorf wrote:
On Monday 31 May 2010, Jesper Eskilson wrote:
On 05/30/2010 02:13 PM, Alexander Neundorf wrote:
That's also ok.
Could you please post the output of the IAR AVR and ARM assemblers when
called without any arguments here ?
(or put them into http://
> > I think, the installation heavily differs depending on cross-compilation
> > environment used (buildroot, scratchbox, etc).
>
> If I remember correctly, scratchbox means running a virtual machine, so from
> this POV building inside scratchbox is not cross compiling, and in that
> regard it shou
I would like to know whether there is some progress on making FindQt4.cmake
friends with cross-compilation.
>>> Not much, unfortunately.
>>>
>> Not a piece of good news.
> There actually has been a slow replacing of things that prevent
> cross-compiling the last few cmake releases.
For later reference, this was indeed the trick, simply updating from
2.8.0 to 2.8.1 solved my issue.
Thanks Dave !
On Mon, May 31, 2010 at 7:26 PM, Mathieu Malaterre
wrote:
> $ ctest --version
> ctest version 2.8.0
>
> I guess I need to update :)
>
> Thanks
>
> On Mon, May 31, 2010 at 7:23 PM, D
30 matches
Mail list logo
