search

eclipse-embed-cdt / eclipse-plugins

The Eclipse Embedded CDT plug-ins for Arm & RISC-V C/C++ developers (formerly known as the GNU MCU Eclipse plug-ins). Includes the archive of previous plug-ins versions, as Releases.
http://eclipse-embed-cdt.github.io/
Eclipse Public License 2.0
558 stars 130 forks source link

Improve the build configurations #434

Open ilg-ul opened 3 years ago

ilg-ul commented 3 years ago

Due to historical reasons, the Eclipse projects used several build tools, initially as JDT only, later maven was added.

As of now, projects have multiple natures:

    <natures>
        <nature>org.eclipse.m2e.core.maven2Nature</nature>
        <nature>org.eclipse.pde.PluginNature</nature>
        <nature>org.eclipse.jdt.core.javanature</nature>
        <nature>org.eclipse.pde.api.tools.apiAnalysisNature</nature>
    </natures>

and

    <natures>
        <nature>org.eclipse.m2e.core.maven2Nature</nature>
        <nature>org.eclipse.pde.FeatureNature</nature>
    </natures>

For compatibility with maven the output folder defined in .classpath is

    <classpathentry kind="output" path="target/classes"/>

In a message posted on embed-cdt-dev list, Alexander mentioned:

But do you have similar error when you compile this project in Eclipse IDE (not with Maven, but with PDE) using the updated target. I'm asking because Eclipse PDE can highlight some issues with .target or with dependencies.

Verify if the current configuration allows the builds that Alexander mentioned, and possibly improve them.

ilg-ul commented 3 years ago

Alexander @ruspl-afed, is there any improvement to consider here?

ruspl-afed commented 3 years ago

I would suggest to employ Eclipse Oomph, it is very helpful to automate workspace setup, perhaps next release cycle.

ilg-ul commented 3 years ago

Eclipse Oomph?!

It looks like I have a new homework to do...

ruspl-afed commented 3 years ago

no need :) I can try it when time permits, it should be similar with what we have in CDT