[OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

[Flanagan, Elizabeth]

On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw at linux.intel.com> wrote:
> On 01/17/2012 12:30 PM, nitin.a.kamble at intel.com wrote:
>>
>> From: Nitin A Kamble<nitin.a.kamble at intel.com>
>>
>> This recipe is needed by guile.
>> And guile is needed for autogen.
>>
>> Signed-off-by: Nitin A Kamble<nitin.a.kamble at intel.com>
>> ---
>>  meta/recipes-support/bdwgc/bdwgc_20110107.bb |   38
>> ++++++++++++++++++++++++++
>>  1 files changed, 38 insertions(+), 0 deletions(-)
>>  create mode 100644 meta/recipes-support/bdwgc/bdwgc_20110107.bb
>>
>> diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> new file mode 100644
>> index 0000000..1aaa5b8
>> --- /dev/null
>> +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
>> @@ -0,0 +1,38 @@
>> +SUMMARY = "A garbage collector for C and C++"
>> +
>> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can
>> be\
>> + used as a garbage collecting replacement for C malloc or C++ new. It
>> allows\
>> + you to allocate memory basically as you normally would, without
>> explicitly\
>> + deallocating memory that is no longer useful. The collector
>> automatically\
>> + recycles memory when it determines that it can no longer be otherwise\
>> + accessed.\
>> +  The collector is also used by a number of programming language\
>> + implementations that either use C as intermediate code, want to
>> facilitate\
>> + easier interoperation with C libraries, or just prefer the simple
>> collector\
>> + interface.\
>> +  Alternatively, the garbage collector may be used as a leak detector for
>> C\
>> + or C++ programs, though that is not its primary goal.\
>> +  Empirically, this collector works with most unmodified C programs,
>> simply\
>> + by replacing malloc with GC_malloc calls, replacing realloc with
>> GC_realloc\
>> + calls, and removing free calls."
>> +
>> +HOMEPAGE = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/"
>> +SECTION = "devel"
>> +LICENSE = "custom"
>
> What's custom?  Is this the correct LICENSE name to use here?
> Beth comments?

custom is certainly not correct. This one isn't a particularly easy one.

openSuSE says BSD-3-Clause. This isn't actually true from what I'm
seeing. It looks to me more like:

LICENSE = "MIT & FSF-Unlimited & GPL-2.0"

linux_threads.c and Makefile.am appear to be MIT.

"Several files supporting GNU-style builds are copyrighted by the Free
Software Foundation, and carry a different license from that given
below." I would assume that that is FSF-Unlimited.

The main portion of the license is MIT.

It does mention that there are some GPL code in here:

"A few of the files needed to use the GNU-style build procedure come with
slightly different licenses, though they are all similar in spirit.  A few
are GPL'ed, but with an exception that should cover all uses in the
collector.  (If you are concerned about such things, I recommend you look
at the notice in config.guess or ltmain.sh.)"

ltmain.sh is GPL-2.0. Is it distributed in the package? If so, then I
would add it to LICENSE.

Doing above should cover all bases.

-b

>
> Sau!
>
>
>> +LIC_FILES_CHKSUM =
>> "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc"
>> +
>> +SRC_URI =
>> "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-7_2alpha5-20110107.tar.bz2"
>> +
>> +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee"
>> +SRC_URI[sha256sum] =
>> "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d"
>> +
>> +PR = "r0"
>> +
>> +S = "${WORKDIR}/bdwgc"
>> +
>> +do_install_append (){
>> +       rm -f ${D}${datadir}/${PN}
>> +}
>> +
>> +inherit autotools
>> +BBCLASSEXTEND = "native nativesdk"
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release