Re: [CMake] Assembly code

Sun, 17 Sep 2006 21:25:07 -0700

Nathan A. Smith wrote: 
On Sun, 2006-09-17 at 09:52 -0700, Brandon J. Van Every wrote:
  
Nathan A. Smith wrote: 
    

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.

CMAKE_CURRENT_SOURCE_DIR is always the source dir.  CMAKE_CURRENT_BINARY_DIR is the source dir if the user is building in-directory, and is part of a parallel out-of-directory build tree if the user is buliding out-of-directory.  It's the user's choice.  It's not correct to think of CMAKE_CURRENT_BINARY_DIR as having a default.

As I said above, CMAKE_CURRENT_BINARY_DIR is your default working directory.  Your OUTPUT will go there unless you tell it otherwise.

However, a MAIN_DEPENDENCY or DEPENDS looks in your CMAKE_CURRENT_SOURCE_DIR by default.  Yes this can get confusing.  This is why I qualify the hell out of things, so I don't have to remember.  If you generate any of your source files, this sort of issue becomes very important.  INCLUDE_DIRECTORIES is also important for whether you search a source or binary directory first.  The Chicken CMakeLists.txt has lotsa working examples of this.

  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)

Don't do that.  If you add or remove files, CMake will have no way to know that your dependencies have changed, and won't automagically re-run.  This is stated in the docs.  Write out your *.s files in a nice long-winded list.  A totally un-fancy list is actually easiest for other people to maintain.

FOREACH(src ${MY_ASM_SRCS})
   GET_FILENAME_COMPONENT(FILE_BASE ${src} NAME_WE)
   SET(SRC ${src})

I forget whether CMake variables are case sensitive or not?  Even if they are case sensitive, this is poor style as they're easily confused.  Also, um, why do you have the SET at all?  You could just use ${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})


ARGS is archaic.  You do not need it.  Just type "COMMAND as -o ${OBJ} ${SRC}"


       SET(MY_ASM_OBJS ${MY_ASM_OBJS} ${OBJ})
ENDFOREACH(src)


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

Your code looks ok as far as SOURCE vs. BINARY directories are concerned.  You've got everything fully qualified so you shouldn't be having any issues.

Your code won't survive on a parallel build though.  The MAIN_DEPENDENCY and DEPENDS of an ADD_CUSTOM_COMMAND will only create "file-level" dependencies.  These are insufficient for parallel builds; you need "target-level" dependencies.  The easy way would be to wrap up your ${OBJ} files thusly:

ADD_CUSTOM_TARGET(all-asm-objs DEPENDS ${MY_ASM_OBJS})
ADD_LIBRARY(x86 ${x86i_src} ${MY_ASM_OBJS})
ADD_DEPENDENCIES(x86 all-asm-objs)

Yes it would be nice if file-level and target-level dependencies were more integrated.  Currently they aren't, and there is no straightforward way in the CMake implementation to make it so.


Cheers,
Brandon Van Every

_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to