Re: [cdt-dev] Eclipse/CDT policy on native libraries?

[Chris Recoskie <recoskie@xxxxxxxxxx>]

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

From:	Alex Blewitt <alex.blewitt@xxxxxxxxx>
To:	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Cc:	CDT Mailing List <cdt-dev@xxxxxxxxxxx>
Date:	11/30/2011 04:21 AM
Subject:	Re: [cdt-dev] Eclipse/CDT policy on native libraries?
Sent by:	cdt-dev-bounces@xxxxxxxxxxx

---

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