[cmake-developers] New OBJECT library feature

[Eric Noulard]

2012/3/19 Brad King <brad.king at kitware.com>:
> On 3/19/2012 2:25 PM, Eric Noulard wrote:
>>
>> 2012/3/19 Brad King<brad.king at kitware.com>:
>>
>>> Can you enumerate use cases when the order of objects matters?  Unlike
>>> static libraries *all* objects will be included.  If there are duplicate
>>> symbols it is an error.  If there are not duplicate symbols then how
>>> does order matter?
>>
>>
>> The custom command likn step looks like:
>> COMMAND ${CMAKE_LINKER} --oformat binary -Ttext ${BM_IMAGE_ADDRESS}
>> -melf_i386 -e _start -o ${BM_APPNAME}.bin ${BM_STARTUPOBJ}
>> --start-group $<TARGET_LINKER_FILE:system>  $<TARGET_LINKER_FILE:xc>
>> $<TARGET_LINKER_FILE:${BM_APPNAME}>  --end-group ${BM_LDSCRIPT}
>>
>> ${BM_STARTUPOBJ} is the specific object file compiled on its own using
>> custom command.
>
>
> I can imagine some cross compiling toolchains may want the object with
> the entry point to come first.

You may be right,
I did ask the question to the initial author, I'd like to understand why.

>> Now that I think about it, before that I was forced to create a custom
>> command in order
>> to compile the file ('with the same option as the one compiled by
>> add_library)
>> but now I will be able to build an "OBJECT library" containing a single
>> file
>> and refer to it using $<TARGET_OBJECTS:objlib>  which is perfectly fine
>> for
>> ensuring the ordering I may need for the link step.
>
> Note that $<TARGET_OBJECTS:...> is not a full generator expression that
> can be used from add_custom_command.  That is also reserved for the
> future (which is why I chose that syntax).  Currently it is just a
> special source file syntax recognized by add_library and add_executable.

Ok, then I may not be able to test it in this particular context.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org