On 3/14/26 08:32, Norbert Grundmann wrote:
Hello Ronald,
thanks for the comments... :-)
I think I will take another approach to build eclipse in future on
FreeBSD. About 2-3 year ago I made a lot patches to make version 4.32
work - the previous one was 4.24. It took a lot of hours. After months
someone took over and created a github repository with FreeBSD stuff,
which I took as the basis. The maintainer of that repo also creates
*.tar.gz files which contain a full FreeBSD compilation / package, but
not usable the pkg way.
[My notes/questions below are general/generic, not based in a detailed
analysis of java/eclipse details.]
Such a file exists that includes the compilation/package for each and
every combination of the following? [as things stand now]:
) supported arch for the port-package
(amd64 vs. aarch64 vs. i386 . . .)
) quarterly [2026Q1] (all but main below)
vs. latest (all 4 of the below, including main)
) 13.5, 14.3 (14.4 next), 15.0 (15.1 next), and main [so: 16.0 for now]
Even limited to tier 1 platforms (amd64 and aarch64) that is 2*(3+4)==14
combinations that each have a separate port-package built and
distributed by the official FreeBSD build servers. Are all of those
covered?
(i386 is still having port-packages built for 13.5 and 14.3 as well.
armv7 and the rest are not building such at all, according to
<https://people.freebsd.org/~dbaio/pkg-master-report.html> and what it
shows for " latest " and " quarterly ", no _ in those Set names.)
And, different FreeBSD build servers can use different versions of the
port-tree's in overlapping time frames for build activity. So each
combination can get into dealing with that type of distinction as well.
Are the *.tar.gz based on using the same OPTIONS settings as for
official builds? What about other configuration details that might
change the build results?
So why recompile?
See above and more later below.
I want to take his *.tar.gz
file, extract and do the needed post-install steps. The end should a
"normal" package usable for FreeBSD :-)
The first steps of this approach seems to work... I would like to
check
before I submit and before other people would confirm, that it works.
What do you think? This way is more easy and does not use a long
compilation time - just seconds for download and prepare. And it is
less error lasting ;-)
I doubt that taking externally built binaries not built by the FreeBSD
port-package build servers from a port that uses source code would be an
acceptable security risk for the official FreeBSD ports folks to
allow such.
Also, it is not obvious that an externally built port-package is always
built in a fully compatible way with the officially built dependencies
that would be involved in each and every official bulk build. A similar
point goes for various combinations listed above possibly using
different tool chains to do builds. Also, how would the update timing
manage to match with the FreeBSD build server bulk build runs for each
of those combinations listed earlier? (They various combinations are not
synchronized and, overall, span widely distinct build time frames.)
Some port-packages that have java/eclipse as a dependency may also
otherwise depend on some of the same dependencies that java/eclipse
does. Mismatched versions of those need not be coherent for overall
operation to actually run and work.
At various times, quarterly and latest need not match for what versions
of dependencies and/or tool-chains are needed.
There is a lot involved in keeping the official port-package build
combinations operational. Things to not arbitrarily mix and match in a
working way.
Of course I will depend on this github repository and data. But that I
did the last versions, too...
Regards, Norbert
On 3/13/26 13:52, Ronald Klop wrote:
Rereading your mail I saw some more concerns you mention.
1. When developing your port for main it can be easier to install
dependencies for main also. That gives consistency to what is
upstream.
2. As long as the maintainer of maven39 does not merge the changes to
the quarterly branch, you don't need to do anything for quarterly. But
keep the 4.38 tag unchanged in github.
3. Your https://github.com/NorbertXYZ/eclipse repo has a nice
README.md, maybe add something similar to the eclipse-maven repo with
instructions to your future self on how you did things. 😀 I totally
recognize going back to some project years later and wondering how
things worked.
If you get stuck, there are probably some people here or on java@ that
want to help further.
NB: it can really help to keep ports@ in the cc:, if you want feedback
from others too.
Regards,
Ronald.
