[CMake] cmake 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables

Bill Hoffman bill.hoffman at kitware.com
Wed Nov 16 12:05:39 EST 2011


On 11/16/2011 4:43 AM, Michael Hertling wrote:
> On 11/15/2011 06:04 PM, Bill Hoffman wrote:
>> On 11/15/2011 11:52 AM, Michael Hertling wrote:
>>
>>> Could you boild down this issue to a minimal and self-sufficient example
>>> - i.e. a project working with 2.6 (quite old) but failing with 2.8 - and
>>> post it here for further investigation?
>>>
>> There was a bug created for this, and the problem found.  The cmake code
>> was marking the .h file as an object file.  Must have been a bug fix in
>> CMake that allowed the .h to be treated as an object file.
>>
>> See here for information:
>> http://public.kitware.com/Bug/view.php?id=12575
>
> Hi Bill,
>
> many thanks for this hint. Perhaps, I might take the opportunity
> and ask a related question. In [1], I noted that a file declared
> as EXTERNAL_OBJECT is delivered to the linker only if it has a
> name extension mentioned in CMAKE_<LANG>_IGNORE_EXTENSIONS, and
> this variable isn't accessible to the user. IMO, this is wrong;
> instead, EXTERNAL_OBJECT files should be supplied to the linker
> regardless of their name extensions, i.e. the relevant blocks
> within cmMakefileTargetGenerator::WriteTargetBuildRules() from
> Source/cmMakefileTargetGenerator.cxx should be swapped. That's
> also what the user expects from the EXTERNAL_OBJECT property's
> documention, as the limitation to the ignored extensions isn't
> mentioned. Is there a reason why this restriction is applied?
>

If someone explicitly sets a property on a file, then CMake should honor 
that property.  They should be able to have files that end in .foobar 
that have object code in them.  It is not quite the same thing as adding 
something to a source list that needs to be there just so it will show 
up in an IDE.   The ignore stuff is only directed at the source lists.

-Bill



More information about the CMake mailing list