[ITP] chicken-4.9.0.1

[ITP] chicken-4.9.0.1

[Christian Kellermann]

Dear List,

I am a core developer of the CHICKEN scheme system. We have supported
building and running CHICKEN on cygwin for almost a decade now. However
I noticed that the current cygwin package has been outdated for years.

The current version that's listed is 3.4.0-0 which has been discontinued
since 2006(?)...

So I'd like to propose an update of said package to the current stable
version as noted in the subject.

CHICKEN scheme has been packages in SuSe, Redhat and Debian for quite a
while. As an example have a look at

http://rpmfind.net//linux/RPM/fedora/devel/rawhide/i386/c/chicken-4.9.0.1-2.fc22.i686.html

I have generated a new port with the following cygport file:

--8<---------------cut here---------------start------------->8---
# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
MAKEOPTS="PLATFORM=cygwin"


src_compile() {
        cd ${S}
	cygmake
}

src_install() {
	cd ${S}
	cygmake install
}
--8<---------------cut here---------------end--------------->8---

The CHICKEN build system uses make only and builds in the source
directory. The platform has to be passed on as shown above.

As I only have access to a 32bit Windows Version (7) atm I am unable to
test this for 64-bit builds.

As per your requirements for new submissions I have included the
setup.hint file:

--8<---------------cut here---------------start------------->8---
category: interpreters
requires:  make gcc-core gcc-g++
sdesc: "A practical and portable scheme system."
ldesc: "A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."
--8<---------------cut here---------------end--------------->8---


Maybe the old one from the 3.4.0 port could be used… The gcc-g++ is not
needed for building but there are FFI features included in the core
library that will use the C++ compiler for interfacing with C++
libraries. I am unsure how to express this potential dependency, maybe
hand that back to the user to decide?

In case you want to have a look at the generated packages, you can find
them here in the usual directory layout here:

https://pestilenz.org/~ckeen/cygwin-ports/

As I am just using cygport with the file above all these are easily
generated.

I have probably forgotten something obvious or missed something in your
detailed documentation so I appreciate any comments on this.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

On 12/10/2014 12:25 PM, Christian Kellermann wrote:
> Dear List,
>
> I am a core developer of the CHICKEN scheme system. We have supported
> building and running CHICKEN on cygwin for almost a decade now. However
> I noticed that the current cygwin package has been outdated for years.

As the previous maintainer is missing from at least 2011...

> The current version that's listed is 3.4.0-0 which has been discontinued
> since 2006(?)...
>
> So I'd like to propose an update of said package to the current stable
> version as noted in the subject.

so it is a ITA (joking with our acronym style)

> CHICKEN scheme has been packages in SuSe, Redhat and Debian for quite a
> while. As an example have a look at
>
> http://rpmfind.net//linux/RPM/fedora/devel/rawhide/i386/c/chicken-4.9.0.1-2.fc22.i686.html
>
> I have generated a new port with the following cygport file:
>
> --8<---------------cut here---------------start------------->8---
> # package name
> NAME="chicken"
> VERSION=4.9.0.1
> RELEASE=1
>
> # setup.hint generation
> CATEGORY="interpreters"
> SUMMARY="A practical and portable scheme system."
> DESCRIPTION="A practical and portable scheme system.
> CHICKEN is a compiler for the Scheme programming language. CHICKEN
> produces portable and efficient C, supports almost all of the R5RS
> Scheme language standard, and includes many enhancements and
> extensions."
>
> REQUIRES="make gcc-core gcc-g++"
>
> # source and patch files
> SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
> MAKEOPTS="PLATFORM=cygwin"
>
>
> src_compile() {
>          cd ${S}
> 	cygmake
> }
>
> src_install() {
> 	cd ${S}
> 	cygmake install
> }
> --8<---------------cut here---------------end--------------->8---
>
> The CHICKEN build system uses make only and builds in the source
> directory. The platform has to be passed on as shown above.
>
> As I only have access to a 32bit Windows Version (7) atm I am unable to
> test this for 64-bit builds.

 >>> Compiling chicken-4.9.0.1-1.x86_64
"make" -f ./Makefile.cygwin CONFIG= all
make[1]: Entering directory 
'/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chick 
                en-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H 
-DC_ENABLE_PTABLES -c a 
pply-hack.x86.S -o apply-hack.x86.o
apply-hack.x86.S: Assembler messages:
apply-hack.x86.S:35: Error: operand type mismatch for `call'
rules.make:184: recipe for target 'apply-hack.x86.o' failed
make[1]: *** [apply-hack.x86.o] Error 1
make[1]: Leaving directory 
'/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chicke 
                 n-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
GNUmakefile:54: recipe for target 'all' failed

I guess you need use apply-hack.x86-64.S for 64bit.
How is it  managed on Linux ?

Time to move to a minimal config system upstream ?

> In case you want to have a look at the generated packages, you can find
> them here in the usual directory layout here:
>
> https://pestilenz.org/~ckeen/cygwin-ports/
>
>
> Kind regards,
>
> Christian

Regards
Marco

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Marco Atzeri <marco.atzeri@gmail.com> [141210 13:28]:
> >As I only have access to a 32bit Windows Version (7) atm I am unable to
> >test this for 64-bit builds.
> 
> >>> Compiling chicken-4.9.0.1-1.x86_64
> "make" -f ./Makefile.cygwin CONFIG= all
> make[1]: Entering directory
> '/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chick
> en-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
> gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES
> -c a pply-hack.x86.S -o apply-hack.x86.o
> apply-hack.x86.S: Assembler messages:
> apply-hack.x86.S:35: Error: operand type mismatch for `call'
> rules.make:184: recipe for target 'apply-hack.x86.o' failed
> make[1]: *** [apply-hack.x86.o] Error 1
> make[1]: Leaving directory
> '/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chicke
> n-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
> GNUmakefile:54: recipe for target 'all' failed
> 
> I guess you need use apply-hack.x86-64.S for 64bit.
> How is it  managed on Linux ?
> 

There's a shell script that tries to determine the architecture, I
guess it needs to be adjusted for the cygwin 64bit case.

One can force it by passing ARCH=x86-64 as a parameter to make.

> Time to move to a minimal config system upstream ?

I don't understand. If there's an upstream change needed I will get
it in.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

On 12/10/2014 2:14 PM, Christian Kellermann wrote:
> * Marco Atzeri  [141210 13:28]:
>>> As I only have access to a 32bit Windows Version (7) atm I am unable to
>>> test this for 64-bit builds.
>>
>>>>> Compiling chicken-4.9.0.1-1.x86_64
>> "make" -f ./Makefile.cygwin CONFIG= all
>> make[1]: Entering directory
>> '/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chick
>> en-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
>> gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES
>> -c a pply-hack.x86.S -o apply-hack.x86.o
>> apply-hack.x86.S: Assembler messages:
>> apply-hack.x86.S:35: Error: operand type mismatch for `call'
>> rules.make:184: recipe for target 'apply-hack.x86.o' failed
>> make[1]: *** [apply-hack.x86.o] Error 1
>> make[1]: Leaving directory
>> '/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chicke
>> n-4.9.0.1-1.x86_64/src/chicken-4.9.0.1'
>> GNUmakefile:54: recipe for target 'all' failed
>>
>> I guess you need use apply-hack.x86-64.S for 64bit.
>> How is it  managed on Linux ?
>>
>
> There's a shell script that tries to determine the architecture, I
> guess it needs to be adjusted for the cygwin 64bit case.

For what I see, it is not really trying

   ARCH ?= x86

only expecting to receive it.

> One can force it by passing ARCH=x86-64 as a parameter to make.
>
>> Time to move to a minimal config system upstream ?
>
> I don't understand. If there's an upstream change needed I will get
> it in.

I was just suggesting the usage of a "standard" config systems:
Automake, cmake...

This should simplify the porting to systems not available yet
to upstream maintainers with the plus of more easy build in a
separate tree than source one.

Of course is it just my 2c$ suggestion.


> Kind regards,
>
> Christian

Attached a better chicken.cygport that allow the
build on separate tree, identify the architecture
correctly install and package.

This also avoid the creation of not needed
chicken-4.9.0.1-1.src.patch

You still need to verify the check portion,
it seems that the test in place is not fully working
but I could be wrong.

About x86_64 there is still a starting problem

 >>> Compiling chicken-4.9.0.1-1.x86_64
"make" -f ./Makefile.cygwin CONFIG= all
make[1]: Entering directory 
'/cygdrive/e/cyg_pub/tmp/chicken-4.9.0.1-1.src/chicken-4.9.0.1-1.x86_64/build'
gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H 
-DC_ENABLE_PTABLES -c apply-hack.x86-64.S -o apply-hack.x86-64.o
apply-hack.x86-64.S: Assembler messages:
apply-hack.x86-64.S:32: Warning: .type pseudo-op used outside of 
.def/.endef ignored.
apply-hack.x86-64.S:32: Error: junk at end of line, first unrecognized 
character is `_'
rules.make:184: recipe for target 'apply-hack.x86-64.o' failed
make[1]: *** [apply-hack.x86-64.o] Error 1

the line 32 is:

         .type _C_do_apply_hack, @function

Regards
Marco



[-- Attachment #2: chicken.cygport --]
[-- Type: text/plain, Size: 868 bytes --]

# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
MAKEOPTS="PLATFORM=cygwin"


src_compile() {
	lndirs
        cd ${B}
	AR=$(arch)
	if [ $AR = "i686" ]
	  then 
		cygmake ARCH="x86"
	elif [ $AR = "x86_64" ]
	  then 
		cygmake ARCH="x86-64"
	else
	  ECHO "Unknown Architecture"
	fi
}

src_install() {
	cd ${B}
	cyginstall PREFIX=/usr
}

src_test() {
	cd ${B}/tests
	./runtests.sh
}

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Marco Atzeri <marco.atzeri@gmail.com> [141210 15:41]:
> I was just suggesting the usage of a "standard" config systems:
> Automake, cmake...

No, this has been discussed internally befor many times. The project
already moved from autotools, scons, cmake to the current state.
So far it served us very well for a lot of different architectures
with minimal fuss (AIX, Haiku, GNU Hurd, minix, windows). This is
a community land mine.

> Attached a better chicken.cygport that allow the
> build on separate tree, identify the architecture
> correctly install and package.
> 
> This also avoid the creation of not needed
> chicken-4.9.0.1-1.src.patch
> 
> You still need to verify the check portion,
> it seems that the test in place is not fully working
> but I could be wrong.

Also if /usr is the preferred PREFIX it should be set to the same
value when calling make and make install.

Yes, the check portion should be just calling "make check".

> About x86_64 there is still a starting problem
> gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES
> -c apply-hack.x86-64.S -o apply-hack.x86-64.o
> apply-hack.x86-64.S: Assembler messages:
> apply-hack.x86-64.S:32: Warning: .type pseudo-op used outside of .def/.endef
> ignored.
> apply-hack.x86-64.S:32: Error: junk at end of line, first unrecognized
> character is `_'

Thanks insteresting. Which gcc is this? Are you sure you build with
a 64 bit assembler there?

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

On 12/10/2014 3:50 PM, Christian Kellermann wrote:
> * Marco Atzeri <marco.atzeri gmail.com> [141210 15:41]:
>
>> Attached a better chicken.cygport that allow the
>> build on separate tree, identify the architecture
>> correctly install and package.
>>
>> This also avoid the creation of not needed
>> chicken-4.9.0.1-1.src.patch
>>
>> You still need to verify the check portion,
>> it seems that the test in place is not fully working
>> but I could be wrong.
>
> Also if /usr is the preferred PREFIX it should be set to the same
> value when calling make and make install.
>
> Yes, the check portion should be just calling "make check".

It will be nice

>> About x86_64 there is still a starting problem
>> gcc -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES
>> -c apply-hack.x86-64.S -o apply-hack.x86-64.o
>> apply-hack.x86-64.S: Assembler messages:
>> apply-hack.x86-64.S:32: Warning: .type pseudo-op used outside of .def/.endef
>> ignored.
>> apply-hack.x86-64.S:32: Error: junk at end of line, first unrecognized
>> character is `_'
>
> Thanks insteresting. Which gcc is this? Are you sure you build with
> a 64 bit assembler there?

Please note that the 32bit version of the Assembler don't have that
row.


$ gcc --version -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/lto-wrapper.exe
gcc (GCC) 4.8.3
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: x86_64-pc-cygwin
Configured with: 
/cygdrive/i/szsz/tmpp/gcc_old/gcc-4.8.3-5.x86_64/src/gcc-4.8.3/configure 
--srcdir=/cygdrive/i/szsz/tmpp/gcc_old/gcc-4.8.3-5.x86_64/src/gcc-4.8.3 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var 
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share 
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C 
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin 
--target=x86_64-pc-cygwin --without-libiconv-prefix 
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared 
--enable-shared-libgcc --enable-static 
--enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic 
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite 
--enable-threads=posix --enable-libatomic --enable-libgomp 
--disable-libitm --enable-libquadmath --enable-libquadmath-support 
--enable-libssp --enable-libada --enable-libgcj-sublibs 
--disable-java-awt --disable-symvers 
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as 
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix 
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.8.3 (GCC)
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
  /usr/lib/gcc/x86_64-pc-cygwin/4.8.3/cc1.exe -quiet -v -Dunix 
-idirafter 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/../include/w32api 
-idirafter 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api 
help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 
-auxbase help-dummy -version --version -o /tmp/ccV2k3QN.s
GNU C (GCC) version 4.8.3 (x86_64-pc-cygwin)
         compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR 
version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/bin/as.exe 
-v --version -o /tmp/ccM1kYjV.o /tmp/ccV2k3QN.s
GNU assembler version 2.24.51 (x86_64-pc-cygwin) using BFD version (GNU 
Binutils) 2.24.51.20140703
GNU assembler (GNU Binutils) 2.24.51.20140703
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-cygwin'.
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
  /usr/lib/gcc/x86_64-pc-cygwin/4.8.3/collect2.exe --build-id -m i386pep 
--wrap _Znwm --wrap _Znam --wrap _ZdlPv --wrap _ZdaPv --wrap 
_ZnwmRKSt9nothrow_t --wrap _ZnamRKSt9nothrow_t --wrap 
_ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic 
--dll-search-prefix=cyg --tsaware --version 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/crt0.o 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/crtbegin.o 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib -L/lib/../lib 
-L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../.. /tmp/ccM1kYjV.o -lgcc_s 
-lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/default-manifest.o 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/crtend.o
collect2 version 4.8.3
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/bin/ld 
--build-id -m i386pep --wrap _Znwm --wrap _Znam --wrap _ZdlPv --wrap 
_ZdaPv --wrap _ZnwmRKSt9nothrow_t --wrap _ZnamRKSt9nothrow_t --wrap 
_ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic 
--dll-search-prefix=cyg --tsaware --version 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/crt0.o 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/crtbegin.o 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib -L/lib/../lib 
-L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../x86_64-pc-cygwin/lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../.. /tmp/ccM1kYjV.o -lgcc_s 
-lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/../../../../lib/default-manifest.o 
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/crtend.o
GNU ld (GNU Binutils) 2.24.51.20140703
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later 
version.
This program has absolutely no warranty.


>
> Kind regards,
>
> Christian
>

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Marco Atzeri <marco.atzeri@gmail.com> [141210 16:09]:
> >Thanks insteresting. Which gcc is this? Are you sure you build with
> >a 64 bit assembler there?
> 
> Please note that the 32bit version of the Assembler don't have that
> row.

Interesting, we only ran into this with Apple's Mach-O assembler.

It works with a gcc-4.8.3 / 4.9.1 on my debian box, so I have to
see where the difference is.

Does it work for you if you omit the #ifdef block (or comment out
the line)?

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Christian Kellermann <ckeen@pestilenz.org> [141210 16:33]:
> * Marco Atzeri <marco.atzeri@gmail.com> [141210 16:09]:
> > >Thanks insteresting. Which gcc is this? Are you sure you build with
> > >a 64 bit assembler there?
> > 
> > Please note that the 32bit version of the Assembler don't have that
> > row.
> 
> Interesting, we only ran into this with Apple's Mach-O assembler.
> 
> It works with a gcc-4.8.3 / 4.9.1 on my debian box, so I have to
> see where the difference is.
> 
> Does it work for you if you omit the #ifdef block (or comment out
> the line)?

Scratch that, AIUI we need to implement the microsoft calling
convention in this case instead of using System V AMD64 ABI. In the
meantime I can disable the apply hack (which introduces a limit of
the parameters a scheme function can have) until we have a fix
upstream.

Then it should at least work for most cases on that platform.

What do you think?

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Dec 10 16:50, Christian Kellermann wrote:
> * Christian Kellermann <ckeen@pestilenz.org> [141210 16:33]:
> > * Marco Atzeri <marco.atzeri@gmail.com> [141210 16:09]:
> > > >Thanks insteresting. Which gcc is this? Are you sure you build with
> > > >a 64 bit assembler there?
> > > 
> > > Please note that the 32bit version of the Assembler don't have that
> > > row.
> > 
> > Interesting, we only ran into this with Apple's Mach-O assembler.
> > 
> > It works with a gcc-4.8.3 / 4.9.1 on my debian box, so I have to
> > see where the difference is.
> > 
> > Does it work for you if you omit the #ifdef block (or comment out
> > the line)?
> 
> Scratch that, AIUI we need to implement the microsoft calling
> convention in this case instead of using System V AMD64 ABI.

That's definitely necessary when using assembler code.  But look out
for the tiny difference in the data model between Cygwin and Windows.
While WIndows is LLP64, Cygwin is LP64:

  sizeof (long) = 4 (Windows) vs. 8 (Cygwin).

But the Windows datatypes are still Windows datatypes:

  sizeof (LONG) = 4


HTH,
C0rinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

On 12/10/2014 4:33 PM, Christian Kellermann wrote:
> * Marco Atzeri <marco.atzeri@gmail.com> [141210 16:09]:
>>> Thanks insteresting. Which gcc is this? Are you sure you build with
>>> a 64 bit assembler there?
>>
>> Please note that the 32bit version of the Assembler don't have that
>> row.
>
> Interesting, we only ran into this with Apple's Mach-O assembler.
>
> It works with a gcc-4.8.3 / 4.9.1 on my debian box, so I have to
> see where the difference is.

https://sourceware.org/binutils/docs/as/Type.html#Type
see COFF Version

>
> Does it work for you if you omit the #ifdef block (or comment out
> the line)?
>

build stop later at:

gcc -shared -o cygchicken-0.dll -Wl,--dll -Wl,--add-stdcall-alias \
     -Wl,--enable-stdcall-fixup -Wl,--warn-unresolved-symbols \
     -Wl,--dll-search-prefix=cyg -Wl,--allow-multiple-definition \
     -Wl,--allow-shlib-undefined \
     -Wl,--out-implib=libchicken.dll.a -Wl,--export-all-symbols \
     -Wl,--enable-auto-import \
     -Wl,--whole-archive library.o eval.o data-structures.o ports.o 
files.o extra                                s.o lolevel.o utils.o tcp.o 
srfi-1.o srfi-4.o srfi-13.o srfi-14.o srfi-18.o srfi 
             -69.o posixunix.o irregex.o scheduler.o profiler.o stub.o 
expand.o modules.o chi                                cken-syntax.o 
chicken-ffi-syntax.o build-version.o runtime.o apply-hack.x86-64.o 
                            \
     -Wl,--no-whole-archive -lm
runtime.o:runtime.c:(.text+0x24c9e): undefined reference to 
`C_do_apply_hack'
runtime.o:runtime.c:(.text+0x24c9e): relocation truncated to fit: 
R_X86_64_PC32                                 against undefined symbol 
`C_do_apply_hack'
collect2: error: ld returned 1 exit status
rules.make:232: recipe for target 'cygchicken-0.dll' failed
make[1]: *** [cygchicken-0.dll] Error 1



> Kind regards,
>
> Christian
>

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

Hi Marco,

thanks for all your help so far. Could I ask for one more try?

please do a make PLATFORM=cygwin confclean or start from scratch and add
HACK_APPLY=0

to the make options.

Does this compile succeed? Does a make check work then?

We already do this for the mingw "platform", so we should also add
it to cygwin in the 64bit case for now.

Thanks for all your patience! If this succeeds I will send out a
"final" cleaned up version tomorrow and ask for a GTG again.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On 12/10/2014 5:06 PM, Christian Kellermann wrote:
> Hi Marco,
>
> thanks for all your help so far. Could I ask for one more try?
>
> please do a make PLATFORM=cygwin confclean or start from scratch and add
> HACK_APPLY=0

not exactly, it need
   HACKED_APPLY=



> to the make options.
>
> Does this compile succeed? Does a make check work then?
>
> We already do this for the mingw "platform", so we should also add
> it to cygwin in the 64bit case for now.
>
> Thanks for all your patience! If this succeeds I will send out a
> "final" cleaned up version tomorrow and ask for a GTG again.
>
> Kind regards,
>
> Christian
>

I will send you privately the build and check logs.
Likely tomorrow.

Attached latest cygport

Regards

[-- Attachment #2: chicken-4.9.0.1-1.src.patch --]
[-- Type: text/plain, Size: 369 bytes --]

--- origsrc/chicken-4.9.0.1/Makefile.cygwin	2014-06-07 14:24:41.000000000 +0200
+++ src/chicken-4.9.0.1/Makefile.cygwin	2014-12-10 17:37:23.693609000 +0100
@@ -123,7 +123,7 @@ endif
 ifdef SYMBOLGC
 	echo "#define C_COLLECT_ALL_SYMBOLS" >>$@
 endif
-ifdef HACKED_APPLY
+ifneq ($(HACKED_APPLY),)
 	echo "#define C_HACKED_APPLY" >>$@
 endif
 	cat chicken-defaults.h >>$@

[-- Attachment #3: chicken.cygport --]
[-- Type: text/plain, Size: 1391 bytes --]

# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
MAKEOPTS="PLATFORM=cygwin"


src_compile() {
	lndirs
        cd ${B}
	AR=$(arch)
	if [ $AR = "i686" ]
	  then 
		cygmake ARCH="x86"
	elif [ $AR = "x86_64" ]
	  then 
		cygmake ARCH="x86-64" HACKED_APPLY=
	else
	  ECHO "Unknown Architecture"
	fi
}

src_install() {
	cd ${B}
	AR=$(arch)
        if [ $AR = "i686" ]
          then
		cyginstall PREFIX=/usr ARCH="x86"
        elif [ $AR = "x86_64" ]
          then
		cyginstall PREFIX=/usr ARCH="x86-64" HACKED_APPLY=
        else
          ECHO "Unknown Architecture"
        fi
}

src_test() {
        cd ${B}
        AR=$(arch)
        if [ $AR = "i686" ]
          then
                cygmake check PREFIX=/usr ARCH="x86"
        elif [ $AR = "x86_64" ]
          then
                cygmake check PREFIX=/usr ARCH="x86-64" HACKED_APPLY=
        else
          ECHO "Unknown Architecture"
        fi
}

Re: [ITP] chicken-4.9.0.1

[Nathan Thern]

On 12/10/2014 7:28 AM, Marco Atzeri wrote:
> On 12/10/2014 12:25 PM, Christian Kellermann wrote:
>> Dear List,
>>
>> I am a core developer of the CHICKEN scheme system. We have supported
>> building and running CHICKEN on cygwin for almost a decade now. However
>> I noticed that the current cygwin package has been outdated for years.
>
> As the previous maintainer is missing from at least 2011...
>

I'm still here, just _extremely_ rarely and sporadically. Life and a 
real job has pulled me away from hobby programming for some time now, so 
I'm happy to let Christian take over. (Not that programmer isn't a real 
job, it's just not _my_ real job.)

best regards,
Nate Thern

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]

Hi Christian,

On Dec 10 12:25, Christian Kellermann wrote:
> Dear List,
> 
> I am a core developer of the CHICKEN scheme system. We have supported
> building and running CHICKEN on cygwin for almost a decade now. However
> I noticed that the current cygwin package has been outdated for years.

The maintainer of the package disappeared long ago, unfortunately...

> The current version that's listed is 3.4.0-0 which has been discontinued
> since 2006(?)...

...and there's still no 64 bit package of chicken for that reason.

> So I'd like to propose an update of said package to the current stable
> version as noted in the subject.

The problem is just this:  We need a maintainer for the package.
Somebody who's willing to do the packaging, manage updates, and
monitors the cygwin mailing list for user's problems.

Are you willing to take over Cygwin maintainership of the package?

> CHICKEN scheme has been packages in SuSe, Redhat and Debian for quite a
> while. As an example have a look at
> 
> http://rpmfind.net//linux/RPM/fedora/devel/rawhide/i386/c/chicken-4.9.0.1-2.fc22.i686.html
> 
> I have generated a new port with the following cygport file:
> 
> --8<---------------cut here---------------start------------->8---
> # package name
> NAME="chicken"
> VERSION=4.9.0.1
> RELEASE=1
> 
> # setup.hint generation
> CATEGORY="interpreters"
> SUMMARY="A practical and portable scheme system."
> DESCRIPTION="A practical and portable scheme system.
> CHICKEN is a compiler for the Scheme programming language. CHICKEN
> produces portable and efficient C, supports almost all of the R5RS
> Scheme language standard, and includes many enhancements and
> extensions."
> 
> REQUIRES="make gcc-core gcc-g++"
> 
> # source and patch files
> SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
> MAKEOPTS="PLATFORM=cygwin"
> 
> 
> src_compile() {
>         cd ${S}
> 	cygmake
> }
> 
> src_install() {
> 	cd ${S}
> 	cygmake install
> }
> --8<---------------cut here---------------end--------------->8---
> 
> The CHICKEN build system uses make only and builds in the source
> directory. The platform has to be passed on as shown above.

Building in the source dir is usually not the right way to do it.  You
potentially end up with files in the source dir which are included in
the patch file of the source archive.  That's what cygport's "lndirs"
command is for; symlinking the sources into the build dir for build
systems not supporting building outside the source dir (which usually is
simple when using autoconf).

> As I only have access to a 32bit Windows Version (7) atm I am unable to
> test this for 64-bit builds.

You can easily install evaluation versions of 64 bit Windows into a
virtual machine:

  http://www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise
  http://msdn.microsoft.com/en-us/evalcenter/dn205302.aspx

They are valid 90 days (workstation) or 180 days (server versions).

> As per your requirements for new submissions I have included the
> setup.hint file:
> 
> --8<---------------cut here---------------start------------->8---
> category: interpreters
> requires:  make gcc-core gcc-g++
> sdesc: "A practical and portable scheme system."
> ldesc: "A practical and portable scheme system.
> CHICKEN is a compiler for the Scheme programming language. CHICKEN
> produces portable and efficient C, supports almost all of the R5RS
> Scheme language standard, and includes many enhancements and
> extensions."
> --8<---------------cut here---------------end--------------->8---
> 
> 
> Maybe the old one from the 3.4.0 port could be used… The gcc-g++ is not
> needed for building but there are FFI features included in the core
> library that will use the C++ compiler for interfacing with C++
> libraries. I am unsure how to express this potential dependency, maybe
> hand that back to the user to decide?

I think the gcc-g++ dep is fine.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 13:31]:
> The problem is just this:  We need a maintainer for the package.
> Somebody who's willing to do the packaging, manage updates, and
> monitors the cygwin mailing list for user's problems.
> 
> Are you willing to take over Cygwin maintainership of the package?

I can do so. I will also pass on the cygwin specific knowlegde to
my co-developers so any of us could take care of the port. With
other linux distributions we have a similar link to package maintainers
/ ports lists and it has worked quite well in the past.

If that's not an option for you I humbly suggest the removal of the
old port. It has tons of bugs and we might switch off the infrastructure
behind the old CHICKEN extensions in the future without further
notice.

> You can easily install evaluation versions of 64 bit Windows into a
> virtual machine:
> 
>   http://www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise
>   http://msdn.microsoft.com/en-us/evalcenter/dn205302.aspx

Thanks I will have a look. What's the cygwin way of detecting whether
we build for 32 or 64 bit? I'd use that to switch options then.

> > Maybe the old one from the 3.4.0 port could be used… The gcc-g++ is not
> > needed for building but there are FFI features included in the core
> > library that will use the C++ compiler for interfacing with C++
> > libraries. I am unsure how to express this potential dependency, maybe
> > hand that back to the user to decide?
> 
> I think the gcc-g++ dep is fine.

Thanks.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Dec 10 14:18, Christian Kellermann wrote:
> * Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 13:31]:
> > The problem is just this:  We need a maintainer for the package.
> > Somebody who's willing to do the packaging, manage updates, and
> > monitors the cygwin mailing list for user's problems.
> > 
> > Are you willing to take over Cygwin maintainership of the package?
> 
> I can do so. I will also pass on the cygwin specific knowlegde to
> my co-developers so any of us could take care of the port. With
> other linux distributions we have a similar link to package maintainers
> / ports lists and it has worked quite well in the past.
> 
> If that's not an option for you I humbly suggest the removal of the
> old port. It has tons of bugs and we might switch off the infrastructure
> behind the old CHICKEN extensions in the future without further
> notice.

No, that's fine, thank you.  And we can remove the old chicken port
either way.

> > You can easily install evaluation versions of 64 bit Windows into a
> > virtual machine:
> > 
> >   http://www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise
> >   http://msdn.microsoft.com/en-us/evalcenter/dn205302.aspx
> 
> Thanks I will have a look. What's the cygwin way of detecting whether
> we build for 32 or 64 bit? I'd use that to switch options then.

${ARCH} is i686 or x86_64.  Or you can test like this:

  if defined ARCH_i686
  then
    ...
  fi
  if defined ARCH_x86_64
  then
    ...
  fi


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 14:58]:
> > Thanks I will have a look. What's the cygwin way of detecting whether
> > we build for 32 or 64 bit? I'd use that to switch options then.
> 
> ${ARCH} is i686 or x86_64.  Or you can test like this:
> 
>   if defined ARCH_i686
>   then
>     ...
>   fi
>   if defined ARCH_x86_64
>   then
>     ...
>   fi

Thanks for all your help!

Here's an updated version of the cygport file including your suggestion:

--8<---------------cut here---------------start------------->8---
# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
MAKEOPTS="PLATFORM=cygwin"




src_compile() {
	lndirs
	cd ${B}
	if defined ARCH_i686
	then
		CHICKEN_ARCH="x86"

	fi
	if defined ARCH_x86_64
	then
	        CHICKEN_ARCH="x68-64"
	fi
	cygmake ARCH=${CHICKEN_ARCH}
}

src_install() {
	cd ${B}
	cygmake DESTDIR=${D} install
}
--8<---------------cut here---------------end--------------->8---

The files on http://pestilenz.org/~ckeen/cygwin-ports/ have
been updated accordingly.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On Dec 10 15:31, Christian Kellermann wrote:
> * Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 14:58]:
> > > Thanks I will have a look. What's the cygwin way of detecting whether
> > > we build for 32 or 64 bit? I'd use that to switch options then.
> > 
> > ${ARCH} is i686 or x86_64.  Or you can test like this:
> > 
> >   if defined ARCH_i686
> >   then
> >     ...
> >   fi
> >   if defined ARCH_x86_64
> >   then
> >     ...
> >   fi
> 
> Thanks for all your help!
> 
> Here's an updated version of the cygport file including your suggestion:
> 
> --8<---------------cut here---------------start------------->8---
> # package name
> NAME="chicken"
> VERSION=4.9.0.1
> RELEASE=1
> 
> # setup.hint generation
> CATEGORY="interpreters"
> SUMMARY="A practical and portable scheme system."
> DESCRIPTION="A practical and portable scheme system.
> CHICKEN is a compiler for the Scheme programming language. CHICKEN
> produces portable and efficient C, supports almost all of the R5RS
> Scheme language standard, and includes many enhancements and
> extensions."
> 
> REQUIRES="make gcc-core gcc-g++"
> 
> # source and patch files
> SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
> MAKEOPTS="PLATFORM=cygwin"
> 
> 
> 
> 
> src_compile() {
> 	lndirs
> 	cd ${B}
> 	if defined ARCH_i686
> 	then
> 		CHICKEN_ARCH="x86"
> 
> 	fi
> 	if defined ARCH_x86_64
> 	then
> 	        CHICKEN_ARCH="x68-64"
                              ^^^
                              this looks wrong.

If you want upload rights for your packages as soon as they are GTG,
please follow the instructions at
https://sourceware.org/cygwin-apps/package-upload.html


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 15:45]:
> > 	        CHICKEN_ARCH="x68-64"
>                               ^^^
>                               this looks wrong.

Oops, thanks. Consider it fixed.

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 13:31]:
> > The CHICKEN build system uses make only and builds in the source
> > directory. The platform has to be passed on as shown above.
> 
> Building in the source dir is usually not the right way to do it.  You
> potentially end up with files in the source dir which are included in
> the patch file of the source archive.  That's what cygport's "lndirs"
> command is for; symlinking the sources into the build dir for build
> systems not supporting building outside the source dir (which usually is
> simple when using autoconf).

Is this the right approach then?

rc_compile() {
        lndirs
        cd ${B}
        cygmake
}

src_install() {
        cd ${B}
        cygmake install
}

I have to say while the documentation is detailed I mostly have a
look at the provided examples and try to read up on the individual
function. Is there an overview document somewhere that explains how
this is supposed to fit together?

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Dec 10 14:34, Christian Kellermann wrote:
> * Corinna Vinschen <corinna-cygwin@cygwin.com> [141210 13:31]:
> > > The CHICKEN build system uses make only and builds in the source
> > > directory. The platform has to be passed on as shown above.
> > 
> > Building in the source dir is usually not the right way to do it.  You
> > potentially end up with files in the source dir which are included in
> > the patch file of the source archive.  That's what cygport's "lndirs"
> > command is for; symlinking the sources into the build dir for build
> > systems not supporting building outside the source dir (which usually is
> > simple when using autoconf).
> 
> Is this the right approach then?
> 
> rc_compile() {
>         lndirs
>         cd ${B}
>         cygmake
> }
> 
> src_install() {
>         cd ${B}
>         cygmake install
> }

Yes, that's it.

> I have to say while the documentation is detailed I mostly have a
> look at the provided examples and try to read up on the individual
> function. Is there an overview document somewhere that explains how
> this is supposed to fit together?

Uh, I'm not sure.  I only look into the given cygport files myself,
or look into /usr/share/doc/cygport/manual.html if I'm searching
for something special.  A collection of concise examples might
be nice. :}


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

Hi All!

Based on the feedback of Marco and Corinna, I propose the following
cygport file for the chicken upgrade:

# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"

AR=$(arch)
if [ $AR = "i686" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86"
elif [ $AR = "x86_64" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86-64 HACKED_APPLY="
else
   ECHO "Unknown Architecture"
fi

src_compile() {
	lndirs
        cd ${B}
        cygmake 
}

src_install() {
	cd ${B}
	cyginstall
}

src_test() {
        cd ${B}
        cygmake -i check 
}


Marco has provided me with logs from a 64bit build and those look fine.
There might be a minor nitpick that I don't know how to get to work:

I need to update an internal database of available chicken modules.
However due to the internal design, I need to call this either so
that PREFIX equals DESTDIR during make install or the *installed*
binary after unpacking the cygwin package tarball. Is there an
infrastructure for such things?

The last resort would be to tell the user to do it...

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

On Dec 11 10:16, Christian Kellermann wrote:
> Hi All!
> 
> Based on the feedback of Marco and Corinna, I propose the following
> cygport file for the chicken upgrade:
> [...]
> src_install() {
> 	cd ${B}
> 	cyginstall
> }

This is default behaviour so you should be able to do without the
src_install function.

> [...]
> There might be a minor nitpick that I don't know how to get to work:
> 
> I need to update an internal database of available chicken modules.
> However due to the internal design, I need to call this either so
> that PREFIX equals DESTDIR during make install or the *installed*
> binary after unpacking the cygwin package tarball. Is there an
> infrastructure for such things?

Postinstall scripts.  If you install a *.sh script (preferredly called
after your package) into /etc/postinstall,  it will run after every
install and update.

If you add a *.sh into /etc/preremove, it will run before every package
removal and before every update.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141211 11:14]:
> This is default behaviour so you should be able to do without the
> src_install function.
> 
Ok!

> > I need to update an internal database of available chicken modules.
> > However due to the internal design, I need to call this either so
> > that PREFIX equals DESTDIR during make install or the *installed*
> > binary after unpacking the cygwin package tarball. Is there an
> > infrastructure for such things?
> 
> Postinstall scripts.  If you install a *.sh script (preferredly called
> after your package) into /etc/postinstall,  it will run after every
> install and update.
> 
> If you add a *.sh into /etc/preremove, it will run before every package
> removal and before every update.

What's the preferred way with cygports to add them?

Thanks for your patience!

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Dec 11 11:35, Christian Kellermann wrote:
> * Corinna Vinschen <corinna-cygwin@cygwin.com> [141211 11:14]:
> > This is default behaviour so you should be able to do without the
> > src_install function.
> > 
> Ok!
> 
> > > I need to update an internal database of available chicken modules.
> > > However due to the internal design, I need to call this either so
> > > that PREFIX equals DESTDIR during make install or the *installed*
> > > binary after unpacking the cygwin package tarball. Is there an
> > > infrastructure for such things?
> > 
> > Postinstall scripts.  If you install a *.sh script (preferredly called
> > after your package) into /etc/postinstall,  it will run after every
> > install and update.
> > 
> > If you add a *.sh into /etc/preremove, it will run before every package
> > removal and before every update.
> 
> What's the preferred way with cygports to add them?

If you don't use any of the automatisms and special features described
in the cygport manual's postinstall section, I guess you either have
to install the script in your install rule, or you have to install it
manually from the src_install section (uhm... :}).  A doexe command
should do it, I think.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Corinna Vinschen <corinna-cygwin@cygwin.com> [141211 13:30]:
> If you don't use any of the automatisms and special features described
> in the cygport manual's postinstall section, I guess you either have
> to install the script in your install rule, or you have to install it
> manually from the src_install section (uhm... :}).  A doexe command
> should do it, I think.

How about this?

# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"

AR=$(arch)
if [ $AR = "i686" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86"
elif [ $AR = "x86_64" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86-64 HACKED_APPLY="
else
   ECHO "Unknown Architecture"
fi

src_compile() {
	lndirs
        cd ${B}
        cygmake 
}

src_install() {
	cd ${B}
	cyginstall
	cat > ${B}/chicken.sh <<HERE
#!/bin/bash
chicken-install -updatedb
HERE
	exeinto /etc/postinstall
	doexe chicken.sh
	cat > ${B}chicken.sh <<HERE
#!/bin/bash
rm $(chicken-install -repository)/modules.db
HERE
	exeinto /etc/preremove
	doexe chicken.sh
}

src_test() {
        cd ${B}
        cygmake -i check 
}

How do I test the actual install? The tarball itself seems to contain
the right thing and if I unpack it manually it all seems to work.
But you never know...

Otherwise GTG?

Thank you all for your help so far!

Christian


-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On 12/11/2014 2:50 PM, Christian Kellermann wrote:
> * Corinna Vinschen <corinna-cygwin@cygwin.com> [141211 13:30]:
>> If you don't use any of the automatisms and special features described
>> in the cygport manual's postinstall section, I guess you either have
>> to install the script in your install rule, or you have to install it
>> manually from the src_install section (uhm... :}).  A doexe command
>> should do it, I think.
>
> How about this?

[cut]

>
> src_install() {
> 	cd ${B}
> 	cyginstall
> 	cat > ${B}/chicken.sh <<HERE
> #!/bin/bash
> chicken-install -updatedb

  eventually -update-db

> HERE
> 	exeinto /etc/postinstall
> 	doexe chicken.sh
> 	cat > ${B}chicken.sh <<HERE
> #!/bin/bash
> rm $(chicken-install -repository)/modules.db
> HERE
> 	exeinto /etc/preremove
> 	doexe chicken.sh
> }
>

The cygport documentation is not explicit on this argument
but the easy way is to put in CYGWIN-PATCHES two files

   postinstall.sh
   preremove.sh

that will be placed during cyginstall as

   /etc/postinstall/chicken.sh
   /etc/preremove/chicken.sh

Please test the attachments and let me know, so I will
build for you the final x86_64 package

For me is GTG

Regards
Marco


[-- Attachment #2: chicken.cygport --]
[-- Type: text/plain, Size: 953 bytes --]

# package name
NAME="chicken"
VERSION=4.9.0.1
RELEASE=1

# setup.hint generation
CATEGORY="interpreters"
SUMMARY="A practical and portable scheme system."
DESCRIPTION="A practical and portable scheme system.
CHICKEN is a compiler for the Scheme programming language. CHICKEN
produces portable and efficient C, supports almost all of the R5RS
Scheme language standard, and includes many enhancements and
extensions."

REQUIRES="make gcc-core gcc-g++"

# source and patch files
SRC_URI="http://code.call-cc.org/releases/${PV}/${P}.tar.gz"
PATCH_URI="chicken-prepost.patch"

AR=$(arch)
if [ $AR = "i686" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86"
elif [ $AR = "x86_64" ]
then
   MAKEOPTS="PREFIX=/usr PLATFORM=cygwin ARCH=x86-64 HACKED_APPLY="
else
   ECHO "Unknown Architecture"
fi

src_compile() {
	lndirs
        cd ${B}
        cygmake 
}

src_install() {
	cd ${B}
	cyginstall
}

src_test() {
        cd ${B}
        cygmake -i check 
}

[-- Attachment #3: chicken-prepost.patch --]
[-- Type: text/plain, Size: 370 bytes --]

--- /dev/null	2014-12-11 17:06:18.000000000 +0100
+++ CYGWIN-PATCHES/postinstall.sh	2014-12-11 17:03:44.236009800 +0100
@@ -0,0 +1,2 @@
+#!/bin/bash
+chicken-install -update-db
--- /dev/null	2014-12-11 17:06:29.000000000 +0100
+++ CYGWIN-PATCHES/preremove.sh	2014-12-11 17:04:17.607918600 +0100
@@ -0,0 +1,2 @@
+#!/bin/bash
+rm $(chicken-install -repository)/modules.db

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Marco Atzeri <marco.atzeri@gmail.com> [141211 17:31]:
> Please test the attachments and let me know, so I will
> build for you the final x86_64 package

Thanks, the attached files are OK.

Now how shall I proceed?

Thanks,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

On 12/15/2014 3:45 PM, Christian Kellermann wrote:
> * Marco Atzeri <marco.atzeri gmail.com> [141211 17:31]:
>> Please test the attachments and let me know, so I will
>> build for you the final x86_64 package
>
> Thanks, the attached files are OK.
>
> Now how shall I proceed?
>
> Thanks,
>
> Christian
>

Follow instructions here
https://sourceware.org/cygwin-apps/package-upload.html

You will find the 64 bit files here
http://matzeri.altervista.org/x86_64/chicken/


Regards
Marco

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

Christian,
any problem with the instructions ?

On 12/15/2014 4:00 PM, Marco Atzeri wrote:
> On 12/15/2014 3:45 PM, Christian Kellermann wrote:
>> * Marco Atzeri <marco.atzeri gmail.com> [141211 17:31]:
>>> Please test the attachments and let me know, so I will
>>> build for you the final x86_64 package
>>
>> Thanks, the attached files are OK.
>>
>> Now how shall I proceed?
>>
>> Thanks,
>>
>> Christian
>>
>
> Follow instructions here
> https://sourceware.org/cygwin-apps/package-upload.html
>
> You will find the 64 bit files here
> http://matzeri.altervista.org/x86_64/chicken/
>
>
> Regards
> Marco

Re: [ITP] chicken-4.9.0.1

[Christian Kellermann]

* Marco Atzeri <marco.atzeri@gmail.com> [150110 11:00]:
> Christian,
> any problem with the instructions ?

Sorry, none. It seemed that my initial mail for the SSH key has
been lost. I have uploaded the packages as stated in the instructions
and added my mail in the !email file.

I hope all goes well.

What lists do I have to monitor to adjust the packages to potential
infrastructure changes? I'd like to be a good cygwin citizen...

Thanks for your help again!

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

Re: [ITP] chicken-4.9.0.1

[Marco Atzeri]

On 1/26/2015 12:32 PM, Christian Kellermann wrote:
> * Marco Atzeri <marco.atzeri@gmail.com> [150110 11:00]:
>> Christian,
>> any problem with the instructions ?
>
> Sorry, none. It seemed that my initial mail for the SSH key has
> been lost. I have uploaded the packages as stated in the instructions
> and added my mail in the !email file.
>
> I hope all goes well.
Every fine.

>
> What lists do I have to monitor to adjust the packages to potential
> infrastructure changes? I'd like to be a good cygwin citizen...

Tthis one for discussion/communication between package maintainers
and  the general one for possible feedback of users

>
> Thanks for your help again!
>
> Kind regards,
>
> Christian
Regards
Marco

Re: [ITP] chicken-4.9.0.1

[Achim Gratz]

Christian Kellermann writes:
> 	cat > ${B}chicken.sh <<HERE
> #!/bin/bash
> rm $(chicken-install -repository)/modules.db
> HERE
> 	exeinto /etc/preremove
> 	doexe chicken.sh
> }

If you simply drop a dummy modules.db into the installation (and perhaps
remove it in the postinstall script if necessary), then the pre-remove
will be unnecessary.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada