Bug 576772 - Wrong auto-generated makefiles
Summary: Wrong auto-generated makefiles
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 10.4.1   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-20 11:17 EDT by Zack Kesabtsi CLA
Modified: 2021-10-20 11:40 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zack Kesabtsi CLA 2021-10-20 11:17:06 EDT
It is a very common practice to have C/C++ source files in the same folder having the same name but different extensions - e.g timer.c, timer.S, timer.cpp, timer.cxx etc.

In any given folder if there are two source files having the same name but different extensions, then the auto generated makefile produces only one object file (i.e. timer.o) and, if lucky enough, it generates the following warning:

library/timer/subdir.mk:31: warning: overriding recipe for target 'library/timer/timer.o'
library/timer/subdir.mk:24: warning: ignoring old recipe for target 'library/timer/timer.o'

>>>>> In the subdir.mk file it produces something like:

# Add inputs and outputs from these tool invocations to the build variables 
CXX_SRCS += \
..../library/timer/timer.cxx       <<<< source file with .cxx extension

CPP_SRCS += \
..../library/timer/timer.cpp       <<<< source file with .cpp extension

OBJS += \
./library/timer/timer.o            <<<< only one .o file <<< is the problem

CXX_DEPS += \
./library/timer/timer.d 

CPP_DEPS += \
./library/timer/timer.d

obviously, it is not difficult to change the names, but I think this is bug and can easily be modified to have the file extension included in the .o files - e.g. timer-cxx.o, timer-cpp.o etc.
Comment 1 Jonah Graham CLA 2021-10-20 11:40:13 EDT
Hi Zack, Thanks for the bug report. I was really surprised that I couldn't find a duplicate of this one as you are correct it is a common practice. I guess up until now everyone who ran across this just renamed one of their sources. If you are using a Vendor provided CDT (with custom project types / toolchains provided by that vendor) then the vendor may need to be the one to fix the problem.

Realistically, I don't know if anyone will take the time to fix this problem. If you are interested in learning some CDT I would be happy to guide you and help get a first contribution into CDT.

As a starting https://wiki.eclipse.org/CDT/contributing has the getting started guide, and the code that needs to change is that handling "outputType" in the "org.eclipse.cdt.managedbuilder.core.buildDefinitions" extension point https://help.eclipse.org/latest/topic/org.eclipse.cdt.doc.isv/reference/extension-points/org_eclipse_cdt_managedbuilder_core_buildDefinitions.html