[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] FreeBSD eclipse port
|
James,
Thanks for the detail. Sounds like a pretty evolved porting strategy. I
would, however, like to offer an alternative. Eclipse is explicitly
designed to facilitate others (such as yourself) providing alternative
implementations of platform-dependent pieces (e.g., SWT). The fragment
model is the main mechanism at play here.
Consider the solaris-motif and linux-gtk Eclipse drops. They are virtually
identical. In fact, they are just repackagings of common plugins and a
sprinkling of platform-specific fragments. The solaris-motif drop contains
fragments for plugins which have linux/motif-specific behaviour while the
linux-gtk drop has fragments for (typically the same) plugins which have
linux/gtk-specific behaviour. You can overlay both drops on the same
shared filesystem and then run from Solarix or linux. The Eclipse runtime
figures it all out.
So, a "port" can be viewed as providing the relevant plugin fragments for
your OS/WS/Arch. In your case you define the following fragments:
org.eclipse.swt.gtk.freebsd
fragment.xml
os/freebsd/x86/
libswt-gtk-2128.so
libswt-pi-gtk-2128.so
org.eclipse.update.core.freebsd
fragment.xml
os/freebsd/
libupdate.so
org.eclipse.core.resources.freebsd
fragment.xml
os/freebsd/x86
libcore_2_1_0.so
The .so files are your recompiled versions and the fragment.xml files
should look something like the following (replacing the ids and names of
course)
<?xml version="1.0" encoding="UTF-8"?>
<fragment
id="org.eclipse.swt.gtk.freebsd"
name="SWT FreeBSD fragment"
provider-name="your name here"
version="2.1.0"
plugin-id="org.eclipse.swt"
plugin-version="2.1.0">
</fragment>
The only other issue is the executable ("eclipse"). This is a
straightforward binary executable which can be handled in the normal way.
Add the fragment structure and eclipse executable to pretty much any
eclipse build and it will run on freebsd-gtk.
While this is not a "first class" build (in that eclipse.org does not
define a feature structure for it), it highlights one of the main reasons
fragments exist.
Jeff
"James E. Flemer"
<jflemer@xxxxxxx.e To: <eclipse-dev@xxxxxxxxxxx>
du> cc:
Sent by: Subject: Re: [eclipse-dev] FreeBSD eclipse port
eclipse-dev-admin@
eclipse.org
02/09/2003 09:14
PM
Please respond to
eclipse-dev
Hi Jeff, answers are inline.
On Sun, 9 Feb 2003 Jeff_McAffer@xxxxxxxxxx wrote:
> James,
>
> This is interesting. Some questions:
>
> - Can you summarize the two changes you had to make?
I had to switch two linux header files for freebsd ones in
the libupdate sources.
--- plugins/org.eclipse.update.core.linux/src/update.cpp.orig Fri Jan 31
22:36:59 2003
+++ plugins/org.eclipse.update.core.linux/src/update.cpp Fri Jan 31
22:41:45 2003
@@ -3,8 +3,8 @@
* All Rights Reserved.
*/
-# include <sys/types.h>
-# include <sys/statfs.h>
+# include <sys/param.h>
+# include <sys/mount.h>
# include <update.h>
/*
--- end ---
> - When you do the build, do you compile the C code or do you build the
> binaries separately and then just include them?
I rebuild the three libraries and the eclipse launcher. I
use the existing makefiles where possible and just use the
freebsd ports framework for the rest.
> - Can you tell us more about the approach that you are taking?
FreeBSD has a ports collection[1] that is a framework of
makefiles and a few other support files which facilitate
the building and installation of several thousand third
party applications. So I just made a "port" for eclipse,
which builds the three binary libraries and the launcher,
then installs a slew of files in the appropriate place.
[1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
> Some answers:
> - The build process is quite complex. The source builds you download
> include a mess of generated build.xml files. These are generated based on
> the various OS, window system and architecture configurations being
> requested and are only really designed to build what was being built at
the
> time they were generated (e.g., they may to have the OS, WS and ARCH
values
> right in them). Since FreeBSD/gtk is not one of the standard
> configurations you need to generate the build.xmls for that
configuration.
> To do that you should get the "releng builder" (the mechanism that
> generates the build.xmls etc) and update it to know about FreeBSD.
Is this the "releng" builder: org.eclipse.releng.* ? I did
not notice that before; I will take a look at it shortly.
Is there any primer or other docs I could skim to get up to
speed on it? I'll read the source if not. ;-)
> - Also, the build mechanism is an area that we want to look at in 2.2.
> Your input is greatly appreciated.
I think that libswt should be made readily available in a
stand alone package. When I began porting eclipse to
freebsd, I initially worked on a stand alone libswt, and
others on the ports list felt that that would be the best
way to add eclipse to the freebsd ports tree. (It would
also help separate the binary build from the Java build.)
Also FreeBSD users tend to want pure-source distributions
when using the ports tree, so having a cleaner way to
re-build the libraries and the launcher would be optimal.
I believe someone mentioned adding "platform.xml" build
files (or similar) to eclipse, so that the binary
components would become part of the Ant build.
And a final note on the build, when I got the build done,
the "install" target just copied the launcher. I had to
download the prebuilt package and extrapolate the list of
required files to move into /usr/local/eclipse from the
source build directory. Perhaps there is code in the
"releng" source which takes care of this, I will
investigate this.
-James
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
