We need to make sure we carefully separate out the IP versus build issues. The IP issue shouldn’t be anything more complicated than any other IP issue at Eclipse
and is well documented elsewhere.
But as the guys have mentioned, we don’t really have a build farm setup to build native. In fact, I don’t think we’ve rebuilt the current CDT libraries for
a couple of years now. If we want to get serious about adding native code we would need to address that.
The other option is to make sure the feature is well behaved when the native library isn’t there. Our Spawner is like that and has a fallback when the native
library doesn’t load. However, I would still think you need to have builds for the “Big Three” platforms supported by the Ecilpse C/C++ IDE: Windows, Linux, and Mac, and both 32 and 64-bit. I think we have enough of those types of machines around to put a
build farm together if we need to.
Doug.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Recoskie
Sent: Wednesday, November 30, 2011 8:27 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Eclipse/CDT policy on native libraries?
To be 100% clear, the Foundation does not have build machines for every platform supported by Eclipse. It's up to the committers to build native libraries on whatever hardware/OSes they have access to and check in the resulting
binaries. The committers are trusted not to do anything nefarious like add Trojan code to the libraries before they check in the binaries.
Back to your situation...
Option #1: if the source to this native library is already hosted by an established open source project, then typically a contribution would come in via the Orbit project, and they would bundle up the native libraries into fragments. That's IF the license is
compatible with the EPL and IF it comes from somewhere that gives us confidence that we wouldn't be just bundling up someone's pet Trojan and IF it passes an IP review with the foundation.
Option #2: if the copyright holders of the source license it under the EPL and donate the source to Eclipse, then we could add the code to our revision control system and build the binaries ourselves before checking them in.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Alex Blewitt
---11/30/2011 04:21:54 AM---I can't speak authoritatively for the CDT team but there are certainly native fragments that are shi
I can't speak authoritatively for the CDT team but there are certainly native fragments that are shipped with Eclipse as a whole; the most obvious being SWT.
However those are compiled on Eclipse infrastructure. I doubt that you would be able to just put a binary compiled elsewhere into an official Eclipse distribution.
There is also a strict IP process at Eclipse for getting third party code in Eclipse, which is non trivial.
Finally CDT, like Eclipse, runs on many platforms and to be successful the component would either need fallback Java behaviour or be supported natively on each. The SWT team do this for SWT and the onus would be on the CDT team to support this going forwards
if it were added.
Please note that these are my thoughts generally on native code at Eclipse rather than a CDT view; I am only a passing observer.
Alex
Sent from my iPhone 4S
On 30 Nov 2011, at 01:42, Nathan Ridge <zeratul976@xxxxxxxxxxx> wrote:
>
> Hello,
>
> What is the Eclipse/CDT policy for using native libraries?
>
> Suppose I want to contribute code to CDT that makes use of a native
> library (interfaced using JNI/JNA/SWIG/Bridj/ffi etc.).
>
> Can such contribution be accepted?
>
> Let's assume the library in question
> 1) is cross-platform and works on all platforms that Eclipse works on
> 2) is licensed under a permissive open-source license
>
> Thanks,
> Nate
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
