[CMake] Assembly code

[Nathan A. Smith]

On Sun, 2006-09-17 at 09:52 -0700, Brandon J. Van Every wrote:
> Nathan A. Smith wrote: 
> > On Sun, 2006-09-17 at 04:34 -0700, Brandon J. Van Every wrote:
> >   
> > > Brandon J. Van Every wrote: 
> > >     
> > > > My CMakeLists.txt for the Chicken Scheme project has lots of
> > > > examples of ADD_CUSTOM_COMMAND to drive a language (Scheme) that is
> > > > not C/C++.  That might be useful to you.  A development snapshot is
> > > > available at
> > > > http://www.call-with-current-continuation.org/index.html  If it
> > > > doesn't build for you - and I suspect that likely, as we've fixed a
> > > > number of bugs since that snapshot - e-mail me if you want a more
> > > > current distribution.
> > > >       
> > > A new snapshot was recently released, incorporating the bugfixes.  It
> > > should build just fine.
> > > http://www.call-with-current-continuation.org/chicken-2.432.tar.gz
> > > 
> > > 
> > >     
> > Thanks a lot for the example,
> > 
> > It really cleared up most things. I just have one question though.
> > 
> > do all ADD_CUSTOM commands get run in-source?  
> 
> No, your default working directory is your CMAKE_CURRENT_BINARY_DIR.
> That's why I often haven't qualified the actual COMMAND.
> 
> Sometimes I do though.  In particular, for tools that you generate in
> the course of your build, you're going to need things like
> GET_TARGET_PROPERTY(CHICKEN_BOOT_EXE chicken-boot LOCATION).
> Different platforms will have different generated directories; for
> instance, Microsoft Visual Studio will create Debug and Release
> directories.  So, you can't hardwire the directory of a generated
> tool, as it can change.
> 
> > The reason I ask, 
> > CMAKE_CURRENT_BINARY_DIR == CMAKE_CURRENT_SOURCE_DIR  which isn't what I
> > want....
> >   
> 
I thought the default was out-of-source.  I haven't attempted in-source
builds (at least not on purpose).  So, I am confused as why it's doing
it now.

BTW:

code looks like this:

FILE(GLOB MY_ASM_SRCS    *.s)

FOREACH(src ${MY_ASM_SRCS})
   GET_FILENAME_COMPONENT(FILE_BASE ${src} NAME_WE)
   SET(SRC ${src})
   SET(OBJ ${CMAKE_CURRENT_BINARY_DIR}/${FILE_BASE}.o)
   MESSAGE ( ${CMAKE_CURRENT_BINARY_DIR})
   ADD_CUSTOM_COMMAND(OUTPUT ${OBJ}
       MAIN_DEPENDENCY ${SRC}
       COMMAND as 
       ARGS -o ${OBJ} ${SRC})
       SET(MY_ASM_OBJS ${MY_ASM_OBJS} ${OBJ})
ENDFOREACH(src)


ADD_LIBRARY(x86 ${x86i_src} ${MY_ASM_OBJS})

nasa

> 
> Well if you don't want that, build out-of-source.  Realize this is the
> user's choice, however.  You can make errors by assuming things will
> always be built in-source, and you can make errors by assuming things
> will always be built out-of-source.  That said, I think everyone
> should canonically design for out-of-source, as that's what you'll
> have the most trouble with.
> 
> 
> Cheers,
> Brandon Van Every
> 
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake