Add support for FreeBSD

[chirontt]

Update: since there's no objection, I'm now submitting PRs to various Eclipse repositories for this issue. Here's the central TODO list to keep track of various tasks done and/or under way:

• [ ] add support for FreeBSD to eclipse.jdt.debug submodule
  • [ ] eclipse-jdt/eclipse.jdt.debug#676
• [ ] add support for FreeBSD to eclipse.jdt.ui submodule
  • [ ] eclipse-jdt/eclipse.jdt.ui#2170
• [ ] add support for FreeBSD to eclipse.pde submodule
  • [ ] eclipse-pde/eclipse.pde#1726
• [ ] add support for FreeBSD to eclipse.platform submodule
  • [ ] eclipse-platform/eclipse.platform#1831
  • [ ] compile the file system natives for FreeBSD. If cross-compiling from Linux is needed, use the freebsd-cross Docker container as a suitable cross-compile tool - details are in its README file for x86_64 and/or for aarch64.
• [ ] add support for FreeBSD to eclipse.platform.swt submodule
  • [ ] eclipse-platform/eclipse.platform.swt#2044
  • [ ] compile the SWT natives for FreeBSD. If cross-compiling from Linux is needed, use the freebsd-cross Docker container as a suitable cross-compile tool - details are in its README file for x86_64 and/or for aarch64.
• [ ] add support for FreeBSD to eclipse.platform.ui submodule
  • [ ] eclipse-platform/eclipse.platform.ui#2933
• [ ] add support for FreeBSD to equinox submodule
  • [ ] eclipse-equinox/equinox#929
  • [ ] compile the launcher natives for FreeBSD. If cross-compiling from Linux is needed, use the freebsd-cross Docker container as a suitable cross-compile tool - details are in its README file for x86_64 and/or for aarch64.
• [ ] add support for FreeBSD to equinox.p2 submodule
  • [ ] eclipse-equinox/p2#788
• [ ] add support for FreeBSD to eclipse.platform.releng.aggregator supermodule
  • [ ] eclipse-platform/eclipse.platform.releng.aggregator#2994

---

As discussed in #2275

I have been enhancing and building the Eclipse SDKs for FreeBSD in my own fork, and have manually tested them regularly, and successfully, on my own FreeBSD boxes for x86_64 and/or aarch64 architectures. It's time to submit them to the official repos, I guess. Please provide your opinions whether it's worthwhile to officially support FreeBSD builds or not.

I understand that there are no FreeBSD platforms on the official build farm, so it's a bit tricky to officially compile the native binaries for FreeBSD, and thus there won't be any automated tests for the FreeBSD builds (assuming current situation for the near future.) For now, for the native compiling, I have enhanced some existing Docker container to cross-compile the C code from Linux (Alpine Linux, to be exact) to FreeBSD binaries; its README file shows details in cross-compiling the SWT and Equinox launcher binaries to FreeBSD.

If the team supports this FreeBSD build initiative. I will start submitting PRs to various submodule repos, and this issue will become the co-ordination point for the PRs. Of course, any help from the team is quite valuable and is greatly appreciated.

[akurtakov]

Pardon my lack of knowledge but for Linux we have one binary for all Linux distros, are BSDs that different that there can't be one "bsd" build for all (Free, Open, Net...) ?

[chirontt]

I haven't tried the OpenBSD, NetBSD, but I suspect they are all separate OSes, and not separate distributions of an BSD OS, as far as applications are concerned.

Case in point: if you examine the JNA project, they provide separate binary jars for FreeBSD and for OpenBSD. Those jar files contain .so files for their specific OSes, i.e. they can't be used interchangeably.

[HannesWell]

I understand that there are no FreeBSD platforms on the official build farm, so it's a bit tricky to officially compile the native binaries for FreeBSD, and thus there won't be any automated tests for the FreeBSD builds (assuming current situation for the near future.)

If the team supports this FreeBSD build initiative. I will start submitting PRs to various submodule repos, and this issue will become the co-ordination point for the PRs. Of course, any help from the team is quite valuable and is greatly appreciated.

Sorry for the (too) late reply. At the Eclipse PMC we discussed adding support for this platform and as it seems to be common in the FreeBSD community to built the binaries from sources (please correct me if I'm wrong) we decided to support doing all the required changes in the sources to build on FreeBSD but to not accept the built binaries. Another case in point is that, in about a year we can start migrating almost all native code and JNA calls to use Java's new Foreign Function and Memory access API. Once that is completed you just need a JDK for a new platform/arch and no binaries have to be built (except for the launcher exe) at Eclipse side. Therefore I would like the extra effort for now, just to have it replaced in about a year (hopefully). This doesn't mean that this issue or all of the PRs you created are obsolete, some of them just have to be reworked/reduced.

[chirontt]

as it seems to be common in the FreeBSD community to built the binaries from sources

Yes, they rebuild all the binaries and re-package the software to their own package management format, for their end users' consumption.

we decided to support doing all the required changes in the sources to build on FreeBSD but to not accept the built binaries.

I'm not sure whether the binaries can be omitted without causing any Maven build problems on our end? I'll try this build scenario at a later time to find out.

Another case in point is that, in about a year we can start migrating almost all native code and JNA calls to use Java's new Foreign Function and Memory access API

Great, I'll eagerly look forward to this migration, to get rid of these C code which have become problematic in terms of DevOps build facilities and such. Port to HarmonyOS, anyone? or maybe to Windows riscv64? :)

Therefore I would like the extra effort for now, just to have it replaced in about a year (hopefully). This doesn't mean that this issue or all of the PRs you created are obsolete, some of them just have to be reworked/reduced.

I'm thinking of withdrawing this whole PR, in light of the FFM migration. Perhaps I can revive it after that migration. To quote @akurtakov 's comment, "there doesn't seem to be a viable path ahead for this one", and I tend to agree.

In the meantime, I'll keep my FreeBSD fork of this aggregator up to date as a helping port for the FreeBSD folks, as far as I'm able to.

[chirontt]

Closing as there isn't a viable path forward for FreeBSD.