To bring to an end the sorry saga of trying to make a multi-architecture Eclipse build, the conclusion appears to be that it is impossible due to limitations in P2.
Although in my last post, I claimed to have success in having a per-architecture “
configuration” directory and “
eclipse.ini” file, the reality is that P2 leaps to the rescue in breaking what otherwise would be a fine set up. And I don't care how it's supposed to be capitalised.
The problem is twofold:
- An Eclipse P2 profile, written into the
eclipse.p2.data.arealocation is single-architecture by design
- P2 doesn't check what the location of the
eclipse.inifiles are during updates; it just assumes they have the standard values
Earlier attempts of generating two profiles (on a per-architecture basis) succeeded in getting the application off the ground. However, since P2 also writes into
configuration/org.eclipse.equinox.simpleconfigurator/bundles.info, we have to split the configuration directories as well.
Conventionally, the configuration directory is called
configuration, but you can change it with a command-line switch (
-configuration) or with an entry in the
eclipse.ini file. This value is known at runtime (go to the 'About' page and you see it shown at the top) but P2 thinks it's still called
configuration, regardless of what it actually is.
Not only that, but the
eclipse.ini isn't always called
eclipse.ini. The actual lookup is
product.ini, with a fallback to
eclipse.ini, if the product-specific one can't be found. This allows you to rename the launcher to something else, or (originally) to have multiple products in a single location.
Sadly, whilst you can launch a multi-architecture build using the previous case, you can't update it. P2 will write entries out to
configuration, which if you've called them
configuration32 are of no use. Ironically, the plugins do actually get loaded and installed into the
plugins directory; it's just the P2 metadata which is written to the wrong place. In The Good Old Days, you'd have been able to run
eclipse -clean and it would have just worked – though to be honest, a multi-architecture would have just worked then as well.
All of this brings us to the conclusion that a single package, multi-architecture build is not going to happen with products in one folder. It might be possible to have one folder per executable with a shared plugin or feature store; but by the time you get to that, why not just stick all the plugins and features into a local M2_REPO type cache and just run from there?
Notes: yes, there's a bug, so please don't leave a comment asking whether I've raised one. And in all honesty, if you're going to leave a comment with P2 vs p2, then I'd much prefer you spent less time worrying about what people are calling your product and more time on getting it to work.