Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Request] Tool Settings for Unmanaged Makefile projects #284
The closest issue I found was this. I'd like to configure the Tool Settings for specifying the Target Processor in imported Makefile projects (In the previous issue they were referred to as Unmanaged Projects).
Steps to Reproduce
Expected behaviour: [What you expected to happen]
To be able to configure Tool Settings Target Processor even for unmanaged projects.
Actual behaviour: [What actually happened]
Tool Settings can only be enabled if I enable "Generate Makefiles automatically" in C/C++ Build dialog "Builder Settings" tab. Enabling this feature will cause this project build to fail since the project contains subprojects which should not be rebuilt except under specific conditions.
Assuming a fairy comes and with her magic wand we get this setting available for makefile projects, how do you think the unmanaged build, which depends entirely on the definitions in the make files, would benefit from setting the Target processor in the Eclipse page?
I see. Is there another way to solve my problem using Managed builds? I don't know how much leeway I have in modifying Makefiles in Eclipse for managed builds. Would Eclipse overwrite the customized makefiles?
The Eclipse managed build process recreates the build trees in separate folders like Debug/Release.
It parses all source folders for files with known extensions and builds them all. The list of source folders is under your control. You can exclude from build any files in the sources folder.
The GNU MCU Eclipse build plug-ins can handle only managed projects.
There are 2 builders (stuff that convert code in executables) in CDT
Next to these builders runs the Indexer. The indexer takes care of plenty of the gui related stuff and in my eyes makes CDT.
Even though the indexer is so vital for CDT most people do not realize it's existence (read CDT did a great integration job). Once you bump into "proof of the indexer existence" it is often quite hard to "get it"
The "proof of existence" you bumped into is the "indexer configuration". Let me explain:
To work properly the indexer needs to know compiler defined defines and include paths. This info is defined in the compiler and not in ar, make, size.