search

xpack-dev-tools / windows-build-tools-xpack

A binary distribution of the Windows Build Tools (used by Eclipse Embedded CDT)
http://xpack-dev-tools.github.io/windows-build-tools-xpack/
MIT License
192 stars 59 forks source link

eclipse headless build of a Cmake project #29

Open duaneellissd opened 1 month ago

duaneellissd commented 1 month ago

So I have a very large C make project - several hundred C and H files spread across multiple directories in a tree. We cross compile to RISCV and CortexM4 with this, We also ?cross? compile Linux_x86 By subsituting our HAL layer.

On windows we use MicroSemi/Micro-chip RISCV variant of Eclipse and the GCC tool chain.

Suffice it to say: Its not a small project and it is not something I can easily post on line so I'm doing the best I can with description of what I see and what I have tried and what is not working.

What I can do is: (A) Create a Eclipse project Import that project (manually, via the GUI, or from the headless commandline) Please note: what Cmake does is create a makefile project that eclipse can consume, it is not a managed build [I wish it was a managed build] but that is a totally different subject - not this one.

I can (B) Import the project into eclipse - I can do that with the GUI or from the headless command line.

I can (C) then build the project in the GUI and it works.

I can (D) debug the project in the GUI :- YEA!

What I cannot do is (C) - Build the project in headless mode. I really need to _ for "ci/cd" process reasons run a HEADLESS build of the project.

For OTHER NONCMAKE projects I can do both a GUI or HEADLESS/Commandline build - it works just fine, you specify "NAME/ConfigName". My hunch is - CMAKE does NOT* create configuration names like DEBUG and RELEASE it seems to create one called: "Configuration" and/or the HEADLESS BUILD system won't work with CMAKE generated projects in general.

Bottom line: the GUI does not require this - it works just fine with the generated project file, but the HEADLESS fails as described above (also see the log file below)

I consider that a BUG in eclipse CDT because the two BUILD mechanisms should be functionally identical. Clearly they are not.

The LOG FILE snip showing the error

!SESSION 2024-10-25 21:04:12.983 -----------------------------------------------
eclipse.buildId=4.22.0.I20211124-1800
java.version=17.0.1
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -pluginCustomization plugin_customization.ini -application org.eclipse.cdt.managedbuilder.core.headlessbuild -build dijkstra@dijkstra.Debug
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -pluginCustomization plugin_customization.ini -data C:\Innoflight\supervisor\sc_workspaces\dijkstra.Debug -application org.eclipse.cdt.managedbuilder.core.headlessbuild -build dijkstra@dijkstra.Debug

!ENTRY org.eclipse.osgi 4 0 2024-10-25 21:04:15.278
!MESSAGE Application error
!STACK 1
java.lang.NullPointerException: Cannot invoke "org.eclipse.cdt.managedbuilder.core.IConfiguration.getOwner()" because "cfg" is null
    at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.sortConfigs(ManagedBuildManager.java:4430)
    at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.buildConfigurations(ManagedBuildManager.java:4419)
    at org.eclipse.cdt.managedbuilder.internal.core.HeadlessBuilder.buildConfigurations(HeadlessBuilder.java:322)
    at org.eclipse.cdt.managedbuilder.internal.core.HeadlessBuilder.start(HeadlessBuilder.java:710)
    at org.eclipse.cdt.managedbuilder.internal.headlessbuilderapp.HeadlessBuilderWrapper.start(HeadlessBuilderWrapper.java:131)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.base/java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1467)

so - I try to read the .cproject file and I am trying to GUESS what is the name of the configuration I should use after the / in the build command. In my "working" (non-cmake) project, I search for a Configuration name item and I find an entry like this: <cconfiguration ... name=Debug>, more specifically: NON-WORKING CMAKE PROJECT 

<cproject>
    <storageModule moduleId="org.eclipse.cdt.core.settings">
        <cconfiguration id="org.eclipse.cdt.core.default.config.1">
            <storageModule buildSystemId="org.eclipse.cdt.core.defaultConfigDataProvider" id="org.eclipse.cdt.core.default.config.1" moduleId="org.eclipse.cdt.core.settings" name="Configuration">

The working CMAKE created .cproject starts off like this: WORKING NON-CMAKE PROJECT 

<cproject storage_type_id="org.eclipse.cdt.core.XmlProjectDescriptionStorage">
        <storageModule moduleId="org.eclipse.cdt.core.settings">
        <cconfiguration id="ilg.gnuarmeclipse.managedbuild.cross.config.elf.debug.1813790499">
            <storageModule buildSystemId="org.eclipse.cdt.managedbuilder.core.configurationDataProvider" id="ilg.gnuarmeclipse.managedbuild.cross.config.elf.debug.1813790499" moduleId="org.eclipse.cdt.core.settings" name="Debug">

This matches the "/Debug" option I specify on the working command line So I thought I should use /Configuration - and I get the same error (null pointer in Java

I'm looking for suggestions here.

the PART2 of the question - is secondary. Is there any other project generator for Eclipse that can also create Unix Makefiles? Right now, CMake is very lessthenoptimal in bad ways and I would really like another method.

ilg-ul commented 1 month ago

Did you read the https://xpack-dev-tools.github.io/windows-build-tools-xpack/docs/support/ page?

If you think that you identified a bug related to the xPack binary distribution, please clearly describe it.

For Eclipse related questions, please use the Eclipse support channels.

duaneellissd commented 4 weeks ago

Where might I find that?

How did i get here? I started here: https://gnu-mcu-eclipse.github.io/advanced/headless-builds/

I am reporting that the things described on that page do not work. It seems like that would be the correct place to report an issue.

Specifically the "SUPPORT" Link on that page lead me to this github issue list.

ilg-ul commented 4 weeks ago

Eclipse headless builds refer to running Eclipse managed builds from a terminal. This feature never worked properly in Eclipse and it is no longer recommended.

The Eclipse CDT project is hosted on GitHub: https://github.com/eclipse-cdt/cdt.

duaneellissd commented 4 weeks ago

thats nice to learn…

then why does that page not state exactly this? so then the basic idea is never ever use eclipse in a configuration that might require any type of build automaton like continuous integration or continuous delivery…

ilg-ul commented 4 weeks ago

never ever use eclipse in a configuration that might require any type of build automaton like continuous integration or continuous delivery…

I concur.

My personal experience with this is documented in a history page: