New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Tool Settings for Unmanaged Makefile projects #284

Closed
tcwan opened this Issue Mar 26, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@tcwan

tcwan commented Mar 26, 2018

Description

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

  1. File->Import->C/C++->Existing Code as Makefile Project
  2. Configure Project
  3. C/C++ Build->Settings->Tool Settings tab not available.

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.

Versions

  • GNU MCU Eclipse 4.3.2
  • Eclipse CDT Oxygen.2
  • JDK 9
  • macOS High Sierra
  • Docker-based Debian Stretch cross-toolchain arm-linux-gnueabi-* (requires Eclipse Docker Tooling and Docker image
@tcwan

This comment has been minimized.

tcwan commented Mar 26, 2018

FYI, I've documented some of the steps needed to setup Eclipse for cross-compilation with Docker here.

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 26, 2018

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?

@tcwan

This comment has been minimized.

tcwan commented Mar 26, 2018

Hmm. How are the settings defined? e.g. C_FLAGS, CPP_FLAGS, etc.
I can reference them from the Makefile if I know what they are and they'll be used to override the defaults.

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 26, 2018

The settings are internal to Eclipse, they are not reflected out in the environment, so you cannot reference them in the Makefile.

@tcwan

This comment has been minimized.

tcwan commented Mar 26, 2018

Incidentally, in Imported projects, the "Toolchains" tab doesn't list the other GNU tools such as ar, make, size, etc. unlike for case of Managed projects. Only C compiler (gcc) and C++ Compiler (g++) can be specified. Not sure if this is an omission or not.

@tcwan

This comment has been minimized.

tcwan commented Mar 26, 2018

The settings are internal to Eclipse, they are not reflected out in the environment, so you cannot reference them in the Makefile.

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?

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 26, 2018

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.

@jantje

This comment has been minimized.

jantje commented Mar 26, 2018

@tcwan
The naming is confusing and what you are referring to is out of @ilg-ul control.
Let me explain how I see the situation at hand.

There are 2 builders (stuff that convert code in executables) in CDT

  1. Managed build->CDT manages the build for you
  2. Unmanaged builds->Someone manages a makefile to build (probably you)

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.
In managed build the indexer asks the location and name of the compiler to the managed build engine.
In unmanaged build the indexer asks the user. As only the compiler is needed (not ar, make, size) only the compiler is requested.

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 26, 2018

For the indexer to be accurate, it needs to know the exact command line used to compile each file, which plain make builds cannot provide.

@jantje

This comment has been minimized.

jantje commented Mar 26, 2018

For the indexer to be accurate, it needs to know the exact command line used to compile each file, which plain make builds cannot provide.

Indeed: the old adagio still counts: "garbage in is garbage out"

@tcwan

This comment has been minimized.

tcwan commented Mar 28, 2018

Ok thanks. The explanations help me understand the situation better now.
I guess it is a 'all-or-nothing' situation with respect to controlling the build parameters.
I'll close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment