MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016046CMakeCMakepublic2016-04-01 08:562016-06-10 14:21
Reporterstw_sesa 
Assigned Togeoffviola 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSWindowsOS Version7
Product VersionCMake 3.5.1 
Target VersionCMake 3.6Fixed in VersionCMake 3.6 
Summary0016046: GHS Multi Generator: duplicate object file names
DescriptionWhen a target contains multiple files with the same name (in different (sub)folders) the generated object files will have the same names too. Normally this isn't a problem at all, but for GHS MULTI it is as the duplicates are ignored.
Steps To ReproduceCreate a project with a target containing at least two files with the same name like this:
add_library(libdemo test.c subfolder/test.c )

Expected result:
The library contains both test.o and subfolder/test.o

Actual result:
Only one of these source files is compiled and archived in the library due to their name equality.


A sample project is attached, that will build successfully using other C project generators (e.g Makefile), but won't when using GHS MULTI toolchain.
Additional InformationThis could also be either a bug in MULTI Project Manager or intended behaviour. However, from the CMake perspective the results are unexpected.

A workaround for the generator would be to rename the generated object file by emitting a unique object file name with the option "-o <filename>.o" in the generated project files (.gpj).

Is there any CMake workaround? (which doesn't require changing CMake itself)
Maybe there is an project file option that changes that behaviour?
TagsNo tags attached.
Relationships
Attached Fileszip dup_objname_test.zip (1,287) 2016-04-01 08:56
https://public.kitware.com/Bug/file/5665/dup_objname_test.zip
patch 0001-Add-OBJECT_FILE-source-property.patch (2,464) 2016-04-04 10:32
https://public.kitware.com/Bug/file/5667/0001-Add-OBJECT_FILE-source-property.patch
Issue History
Date ModifiedUsernameFieldChange
2016-04-01 08:56stw_sesaNew Issue
2016-04-01 08:56stw_sesaFile Added: dup_objname_test.zip
2016-04-01 10:08Brad KingAssigned To => geoffviola
2016-04-01 10:08Brad KingStatusnew => assigned
2016-04-04 10:32stw_sesaFile Added: 0001-Add-OBJECT_FILE-source-property.patch
2016-04-04 10:37stw_sesaNote Added: 0040804
2016-04-04 12:30geoffviolaNote Added: 0040806
2016-04-05 11:04stw_sesaNote Added: 0040816
2016-04-05 11:06stw_sesaNote Edited: 0040816bug_revision_view_page.php?bugnote_id=40816#r2068
2016-04-07 00:58geoffviolaNote Added: 0040821
2016-04-27 14:34Brad KingNote Added: 0040940
2016-04-27 14:34Brad KingStatusassigned => resolved
2016-04-27 14:34Brad KingResolutionopen => fixed
2016-04-27 14:34Brad KingFixed in Version => CMake 3.6
2016-04-27 14:34Brad KingTarget Version => CMake 3.6
2016-06-10 14:21Kitware RobotNote Added: 0041182
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040804)
stw_sesa   
2016-04-04 10:37   
A workaround would be to let the user define the generated object file name. I've attached "0001-Add-OBJECT_FILE-source-property.patch" for a tiny sample implementation. That code would allow to use the following line in CMakeLists.txt to fix the problem for the example project:

set_property(SOURCE subfolder/test.c PROPERTY "OBJECT_FILE" "test__2.o")

Of course this does not directly solve the initial problem as the user still needs some special handling in his CMake scripts, but at least it gives the possibility to work around the issue.

Are there any problems / side-effects with allowing the user to change the object file name?
(0040806)
geoffviola   
2016-04-04 12:30   
By default Green Hills MULTI does not output object files. CMake is setting the object directory. It may alleviate the problem by not having CMake set the output directory. It would be nice if there was a target generate object files boolean property.

It may also be nice to support an overriding OBJECT_FILE file property.

In the projects that I've worked on, I like to use the source FOLDER property. For example, I would use this code SET_SOURCE_FILES_PROPERTIES(test/test.c PROPERTIES FOLDER "test"). When set according to the directory structure, this property will enable object files to be in different locations.

The below macro might help
#### Creates relevant filters in an IDE solution
#### @param folder_start_at a list of folder names that will be removed in the filter
#### @param sources a list of sources which will be places in folders
macro(setup_IDE_filters folders_start_at sources)
    foreach(source ${sources})
        # remove the leading path
        set(filter_name "${source}")
        foreach(folder_at_start ${folders_start_at})
            string(REGEX REPLACE ".*${folder_at_start}/" "" filter_name "${filter_name}")
        endforeach()
        # remove the filename
        string(REGEX REPLACE "(^|[/\\])[^/\\]+\\.(c|h|cc|cpp|hpp|ld|bsp|int)$" "" filter_name "${filter_name}")
        # change from unix to Windows path delineator
        string(REPLACE "/" "\\" filter_name "${filter_name}")
        source_group("${filter_name}" FILES "${source}")
    endforeach()
endmacro()
(0040816)
stw_sesa   
2016-04-05 11:04   
(edited on: 2016-04-05 11:06)
In the actual project I use a similar macro to group the source files accordingly. Unfortunately this does not help. Neither does setting different "object_dir"s for the source files or removing the "-object_dir=..." setting from the project file(s).

So even when the object files are in different locations or no object_dir is specified it does not work.

The only two workarounds that were working for me yet are:
 - rename the source files or
 - rename the object files (using "-o ...")
(0040821)
geoffviola   
2016-04-07 00:58   
I confirmed your notes, ran some tests, and sent a sample to Green Hills to see if they have a better solution.

It's not a big deal, but I'm a little confused that you didn't need to pass "-non_shared" as a compile option to the demo executable. I ended up adding it to all my configurations to compile an executable.

The patch looks good. The only changes that I could think to make would be to fit the style. There's some discussion of CMake's source code style at http://public.kitware.com/pipermail/cmake-developers/2015-November/027010.html. [^] Can you indent just the curly braces to match Whitesmiths style and send a new patch? To submit the patch, email cmake-developers@cmake.org with the patch as an attachment. It would be nice if you cc geoffrey.viola@asirobots.com, include the bug number somewhere in the subject, and add https://cmake.org/Bug/view.php?id=16046 [^] somewhere in the body.
(0040940)
Brad King   
2016-04-27 14:34   
A fix for this issue was discussed here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16264 [^]

and has been applied:

 GHS: Fix handling of duplicate source filenames
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1703a6d2 [^]
(0041182)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.