[Cmake] different compiler in subdirs ?
Filipe Sousa
filipe.gr.sousa at alunos.ipb.pt
Wed Jun 2 16:01:39 EDT 2004
On Wednesday 02 June 2004 17:40, Eric Wing wrote:
> > From: "Alexander Neundorf"
> > Subject: [Cmake] different compiler in subdirs ?
> >
> > Hi,
> >
> > I'd like to use cmake for cross-compiling.
> > What I would like to do is to have a big source
> > tree, everything "managed"
> > by cmake, where in some directories stuff for the
> > local machine is
> > compiled, but in some other directories sources for
> > an embedded target get
> > compiled. Therefor in these directories not gcc
> > should be used, but e.g
> > arm-elf-gcc and friends.
> > Is there a way to achieve this ? I didn't find a
> > starting point for this
> > until now.
> >
> > Thanks in advance
> > Alex
>
> Hi, I'm hoping somebody else will address this
> question too because I also have almost the exact same
> situation (need to invoke a vxworks compiler).
>
> But until I can figure out a better solution, I've
> been trying two different things for the embedded
> stuff (the non-embedded stuff can use CMake in a
> normal manner).
>
> First, I tried building my own rules using
> ADD_CUSTOM_TARGET, where I invoke the embedded
> compiler directly with the flags I need. But one of
> the problems I've been having though is a "make clean"
> doesn't necessarily clean up the files. I've found a
> little hack where if you make the target name the path
> and name of the file generated, it seems to clean it
> up. However, I don't know if there are any bad issues
> I should be worried about. The other problem I have is
> that our source tree is large and complicated enough
> that I don't know all the dependencies, and using
> ADD_CUSTOM_TARGET requires you to list all the
> dependencies if you expect things to rebuild when, say
> a header file is changed.
>
> So more recently, I've been trying a more convoluted
> system that will invoke a Makefile directly which uses
> GNU make depend to generate the dependency information
> for me and build the system directly. But one problem
> I haven't figured out is how to always ensure Make is
> invoked because CMake will only call it if it thinks a
> listed dependency is changed. I suppose I can find
> some unclean hack for this if I can't find a nice
> elegant solution. Another one of the problems of
> course is I risk losing portability. But since all the
> different platforms I need to support (Solaris, Linux,
> MacOS X) have gcc and GNU tools installed on them,
> this is less of an issue for me.
>
> But another problem I have with this technique is once
> again, cleaning up the files. Since I'm now invoking
> make indirectly through CMake, calling make clean will
> only clean CMake's normally generated files and will
> miss everything generated in my embedded target
> makefile. As far as I know, I can't add any
> instructions to CMake's clean process. So I use
You could add extra files do clean target with properties
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "myfile.cc")
> ADD_CUSTOM_TARGET to create a special target called
> vxclean which will invoke a process to call my
> embedded Makefiles' clean target. However, this won't
> recursively clean all my subdirectories. So my target
> actually invokes a custom Perl script that I wrote
> which will recurse through the CMake build
> subdirectories and invoke make clean. In the end, this
> seems to work, but the user must remember to
> explicitly call "make vxclean" to clean up the
> embedded stuff.
>
>
> Anyway, I hope this might get you started, but
> I would really appreciate hearing some other ideas
> from others out there.
>
> Thanks,
> Eric
>
>
>
>
>
> _______________________________________________
> Cmake mailing list
> Cmake at www.cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://public.kitware.com/pipermail/cmake/attachments/20040602/bf848f7c/attachment.pgp
More information about the Cmake
mailing list