View Issue Details Jump to Notes ] Print ]
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.
Attached Fileszip file icon dup_objname_test.zip [^] (1,287 bytes) 2016-04-01 08:56
patch file icon 0001-Add-OBJECT_FILE-source-property.patch [^] (2,464 bytes) 2016-04-04 10:32 [Show Content]

 Relationships

  Notes
(0040804)
stw_sesa (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2016-04-01 08:56 stw_sesa New Issue
2016-04-01 08:56 stw_sesa File Added: dup_objname_test.zip
2016-04-01 10:08 Brad King Assigned To => geoffviola
2016-04-01 10:08 Brad King Status new => assigned
2016-04-04 10:32 stw_sesa File Added: 0001-Add-OBJECT_FILE-source-property.patch
2016-04-04 10:37 stw_sesa Note Added: 0040804
2016-04-04 12:30 geoffviola Note Added: 0040806
2016-04-05 11:04 stw_sesa Note Added: 0040816
2016-04-05 11:06 stw_sesa Note Edited: 0040816
2016-04-07 00:58 geoffviola Note Added: 0040821
2016-04-27 14:34 Brad King Note Added: 0040940
2016-04-27 14:34 Brad King Status assigned => resolved
2016-04-27 14:34 Brad King Resolution open => fixed
2016-04-27 14:34 Brad King Fixed in Version => CMake 3.6
2016-04-27 14:34 Brad King Target Version => CMake 3.6
2016-06-10 14:21 Kitware Robot Note Added: 0041182
2016-06-10 14:21 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team