headers
Mathieu Malaterre | 1 Jun 2010 09:50
Picon

Re: CTest / UTF-8

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
<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, David Cole <david.cole@...> wrote:
>> ctest 2.8.1 and later should already be generating proper UTF-8... what
>> version of ctest are you using?
>>
>> On Mon, May 31, 2010 at 9:32 AM, Mathieu Malaterre
>> <mathieu.malaterre@...> wrote:
>>>
>>> Hi there,
>>>
>>>  Does anyone know how I can tell ctest to use UTF-8 to generate the
>>> XML files used for uploading results to CDAsh ?
>>>
>>> I have on one hand:
>>>
>>>
>>> Testing/Temporary/LastBuild_20100531-0918.log:/home/mathieu/Projects/CoSMo/trunk/Code/IO/csmModelModificationsLoader.cxx:386:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey | 1 Jun 2010 09:47

Re: Cross-compilation vs FindQt4.cmake

>>>> 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.  It could probably go a bit 
> quicker, but I wanted to be careful to not break things.
Yeah, I greatly appreciate these efforts!
Many packages compile flawlessly for both native and cross-compile builds.
You're right, haste makes waste.:)

--

-- 
Andrey Hippo.
_______________________________________________
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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 0 comments |
headers
Andrey | 1 Jun 2010 12:05

Re: Cross-compilation vs FindQt4.cmake

> > 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 shouldn't need anything special from cmake.
Yes, you're right.
And this emphasizes the difference between various cross-compilation environments and techniques.

> Buildroot doesn't do that, right ?
Right, buildroot doesn't use virtual machines.
It compiles cross-toolchain, some tools and then use them to compile packages for target system.

> > Currently, I'm using some
> > hand-written environment, mostly resembling buildroot. It consists of:
> > 1) host system with general native libraries and utilities;
> > 2) cross-compiled libraries and executables for target system placed at
> > some prefix; 3) special tools, required for cross-compilation and related
> > stuff (cross-toolchain, qmake, image/firmware generators go here).
> >
> > Tools at item 3) usually must match specific requirements on version used.
> > In case of Qt, I have statically compiled qmake, moc, uic, lrelease, etc
> > against exactly the same version of Qt used for target system.
>
> So this seems to be the actual crosscompiling case.
Right.

> If you want to use a specific version of Qt, you have to make sure cmake finds
> the qmake for the Qt you want to use.
That's clear.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jesper Eskilson | 1 Jun 2010 12:35
Picon

Re: Anybody using IAR compiler here ?

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://public.kitware.com/Bug/view.php?id=10176 )
>>
>> The first non-empty line is for ARM and Atmel AVR, respectively:
>>
>>       IAR Assembler V5.41.2.51793/W32 for ARM
>>       IAR Assembler V5.50.0.50277/W32 for Atmel AVR
>
> Thanks :-)
>
> While we are at it, do the C and C++ compilers behave the same way, i.e. print
> the version information when called without arguments ?

Yes.

> How does that output look like then ?

    IAR ANSI C/C++ Compiler V5.41.2.51793/W32 for ARM
    IAR C/C++ Compiler V5.50.0.50277/W32 for Atmel AVR

> Does it differ between the AVR and ARM compilers ? They seemed to be quite
> different in their command lines etc.

They do differ a bit in their command lines, mostly depending on the 
different capabilities. One such difference is that ARM is ELF/Dwarf
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Hoffman | 1 Jun 2010 14:55
Favicon
Gravatar

Re: Generator for NetBeans 6.9

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
chains like gcc, MinGW or CygWin, is this really necessary?
>

Yes, this is a requirement.   The build must be able to be automated for 
a variety of reasons.  I would be surprised if this were not supported 
in some way.   How would one do automated testing?   In the case of 
CMake for a full generator it is needed for:

1. try-compile to work, CMake must be able to try small bits of code to 
do platform inspection.
2. ctest needs this to run builds and tests
3. cmake --build needs it
4. external project needs this to work

If it is not supported, then you should use the makefile approach.

-Bill
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
kent williams | 1 Jun 2010 16:01
Picon

Re: chicken and egg q: Can CMakeLists.txt generate CTestConfig.cmake during configuration?

On Fri, May 28, 2010 at 5:11 PM, David Cole <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 do you think you want to generate it?

Well, we've gotten to the point where we can use ExternalProjects for
all the libraries we depend on (ITK,VTK, etc). We also have
CMakeLists.txt for each of our projects on NITRC that builds all the
prerequisites, then builds the project itself as an external project.

So for each of these projects, there's a CMakeLists.txt file that
differs only in the name of the project, and each of our
CTestConfig.cmake files differ only in the name of the project. So the
next step would be to get rid of the individual files for each
project, and generate them during initial CMake configuration.

Now that I think about it, we could generate the CMakeLists.txt and
CTestConfig.cmake at the top level configuration time, since we're
building our own projects as ExternalProjects.  Again, it could be an
issue of timing -- at configuration time, we'd have to configure those
files into a subdirectory, before configuring the ExternalProject that
needs those files to configure itself.

> If the nightly start time changes, the CDash server also needs to know about
> this.
> If you are just submitting to a different CDash server, you can do that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hariharan | 1 Jun 2010 16:23
Picon

Set variable value based on generated files

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 runs the first time. Is there any way to add a dependency on the file generation step to the "file" command?

_______________________________________________
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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 1 comment |
headers
Kelly Thompson | 1 Jun 2010 16:43

Re: Fortran 90 module output directories, dependency analysis

This can be done using a Fortran compile option.  For gfortran, add the
option "-M<dir>" to CMAKE_Fortran_FLAGS.  

> -----Original Message-----
> From: cmake-bounces@...
[mailto:cmake-bounces@...] On Behalf
Of
> Jed Brown
> Sent: Monday, May 31, 2010 5:41 AM
> To: cmake@...
> Subject: [CMake] Fortran 90 module output directories, dependency analysis
> 
> Is there a way to specify where generated *.mod files will be placed?
> Something analogous to CMAKE_LIBRARY_OUTPUT_DIRECTORY?
> 
> Also, I notice that if I delete a module file, the build fails (unlike
> everything else where it will be properly regenerated).  This is with a
> plain Makefile build, cmake-2.8.1, after a successful complete build:
> 
> $ rm petscmat.mod
> $ make VERBOSE=1
> /usr/bin/cmake -H/home/jed/petsc -B/home/jed/petsc/ompi-complex-int64 --
> check-build-system CMakeFiles/Makefile.cmake 0
> /usr/bin/cmake -E cmake_progress_start /home/jed/petsc/ompi-complex-
> int64/CMakeFiles /home/jed/petsc/ompi-complex-
> int64/CMakeFiles/progress.marks
> make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> make -f CMakeFiles/petsc.dir/build.make CMakeFiles/petsc.dir/depend
> make[2]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> cd /home/jed/petsc/ompi-complex-int64 && /usr/bin/cmake -E cmake_depends
> "Unix Makefiles" /home/jed/petsc /home/jed/petsc /home/jed/petsc/ompi-
> complex-int64 /home/jed/petsc/ompi-complex-int64 /home/jed/petsc/ompi-
> complex-int64/CMakeFiles/petsc.dir/DependInfo.cmake --color=
> make[2]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make -f CMakeFiles/petsc.dir/build.make CMakeFiles/petsc.dir/requires
> make[2]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> make -f CMakeFiles/petsc.dir/build.make CMakeFiles/petsc.dir/src/sys/f90-
> mod/petscmod.F.o.provides.build
> make[3]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> /usr/bin/cmake -E cmake_copy_f90_mod petscsys
> CMakeFiles/petsc.dir/petscsys.mod.stamp GNU
> /usr/bin/cmake -E cmake_copy_f90_mod petscsysdef
> CMakeFiles/petsc.dir/petscsysdef.mod.stamp GNU
> /usr/bin/cmake -E touch CMakeFiles/petsc.dir/src/sys/f90-
> mod/petscmod.F.o.provides.build
> make[3]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make -f CMakeFiles/petsc.dir/build.make CMakeFiles/petsc.dir/src/vec/f90-
> mod/petscvecmod.F.o.provides.build
> make[3]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> /usr/bin/cmake -E cmake_copy_f90_mod petscis
> CMakeFiles/petsc.dir/petscis.mod.stamp GNU
> /usr/bin/cmake -E cmake_copy_f90_mod petscisdef
> CMakeFiles/petsc.dir/petscisdef.mod.stamp GNU
> /usr/bin/cmake -E cmake_copy_f90_mod petscvec
> CMakeFiles/petsc.dir/petscvec.mod.stamp GNU
> /usr/bin/cmake -E cmake_copy_f90_mod petscvecdef
> CMakeFiles/petsc.dir/petscvecdef.mod.stamp GNU
> /usr/bin/cmake -E touch CMakeFiles/petsc.dir/src/vec/f90-
> mod/petscvecmod.F.o.provides.build
> make[3]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make -f CMakeFiles/petsc.dir/build.make CMakeFiles/petsc.dir/src/mat/f90-
> mod/petscmatmod.F.o.provides.build
> make[3]: Entering directory `/home/jed/petsc/ompi-complex-int64'
> /usr/bin/cmake -E cmake_copy_f90_mod petscmat
> CMakeFiles/petsc.dir/petscmat.mod.stamp GNU
> Error copying Fortran module "petscmat".  Tried "PETSCMAT.mod" and
> "petscmat.mod".
> make[3]: *** [CMakeFiles/petsc.dir/src/mat/f90-
> mod/petscmatmod.F.o.provides.build] Error 1
> make[3]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make[2]: ***
[CMakeFiles/petsc.dir/src/mat/f90-mod/petscmatmod.F.o.provides]
> Error 2
> make[2]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make[1]: *** [CMakeFiles/petsc.dir/all] Error 2
> make[1]: Leaving directory `/home/jed/petsc/ompi-complex-int64'
> make: *** [all] Error 2
> 
> 
> Jed
> _______________________________________________
> 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 check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

_______________________________________________
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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 1 comment |
headers
Michael Wild | 1 Jun 2010 16:48
Picon
Gravatar

Re: Set variable value based on generated files


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, so the value of varFoo comes up as empty
> when the build runs the first time. Is there any way to add a dependency on
> the file generation step to the "file" command?

Such a design is very likely to never work properly. Always try very hard to avoid file(GLOB). Presumably
you are using ADD_CUSTOM_COMMAND to generate the files, right? So you should be able to infer the names of
the generated files. It might be a bit more work to program, but is definitely worth the effort.

The problem with file(GLOB) is that CMake is a Meta-buildsystem which generates a build-systems for
various generators. This also means that CMake will not be able to tell when you add or remove files,
requiring you to remember to re-run CMake by hand.

Michael

_______________________________________________
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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 0 comments |
headers
Jed Brown | 1 Jun 2010 17:06

Re: Fortran 90 module output directories, dependency analysis

On Tue, 1 Jun 2010 08:43:43 -0600, "Kelly Thompson" <kgt@...> wrote:
> This can be done using a Fortran compile option.  For gfortran, add the
> option "-M<dir>" 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 options."

2. It only works for gfortran, this is a serious problem if you have to
   support a lot of vendor compilers.  Simply copying the module file to
   the desired destination is a much better solution.

3. The dependencies become even more broken, CMake needs to know where
   this file is generated and what rule is used to produce it.  Hacking
   this in with compiler-specific flags will prevent CMake from knowing
   about it and generating correct build rules.

Jed
_______________________________________________
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 check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 0 comments |

Gmane