| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0016046 | CMake | CMake | public | 2016-04-01 08:56 | 2016-06-10 14:21 | ||||
| Reporter | stw_sesa | ||||||||
| Assigned To | geoffviola | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | x86_64 | OS | Windows | OS Version | 7 | ||||
| Product Version | CMake 3.5.1 | ||||||||
| Target Version | CMake 3.6 | Fixed in Version | CMake 3.6 | ||||||
| Summary | 0016046: GHS Multi Generator: duplicate object file names | ||||||||
| Description | When 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 Reproduce | Create 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 Information | This 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? | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |  dup_objname_test.zip [^] (1,287 bytes) 2016-04-01 08:56 0001-Add-OBJECT_FILE-source-property.patch [^] (2,464 bytes) 2016-04-04 10:32 [Show Content]
| ||||||||
| Relationships | |
| 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. |
| Notes |
| 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 |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |