[CMake] Assembly code

[Brandon J. Van Every]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060917/c348e3d2/attachment-0001.html