[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] When referencing libchicken, take PROGRAM_
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] When referencing libchicken, take PROGRAM_PREFIX into account |
Date: |
Thu, 17 May 2012 13:41:19 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On Wed, May 16, 2012 at 02:12:30PM -0400, Mario Domenech Goulart wrote:
> Hi,
>
> Currently, the build system names libchicken taking PROGRAM_PREFIX into
> account, but the chicken tools don't. `libchicken' is hardcoded in
> chicken tools and tests. That was causing some problems on the
> cross-compiling environment I use at work.
>
> The attached patch makes tools load libchicken according to the name
> generated by the build system.
I applied your patch, but it doesn't take into account PROGRAM_SUFFIX.
Also, turns out there are some problems when building a non-cross
compiler with prefix/suffix (not caused by your patch).
When building it will still try to use the name "libchicken" even though
it should be prepending the PROGRAM_PREFIX and appending PROGRAM_SUFFIX
to chicken. This is because of this line in csc.scm:
(define default-shared-library-files
(list (string-append "-l" (if host-mode INSTALL_LIB_NAME TARGET_LIB_NAME))))
And TARGET_LIB_NAME in defaults.make is simply a hardcoded "chicken".
I started adding this to the system, but then I got horribly confused.
Shouldn't Chicken be using INSTALL_LIB_NAME when it isn't built as
a cross-compiler? ie, isn't it always in host-mode when you didn't
build as a cross compiler?
> It also tries to keep tests working on
> windows, in cases that libchicken has to be copied to the tests dir
> (this is a bit hacky, since the actual lib name is not known from
> scripts, so lib*chicken.dll is copied).
I've tried, and it looks like the runtest.sh has access to all the
environment variables passed to "make". Currently, none of those are
used, so this means that after building and installing, a line like
"gmake PLATFORM=bsd PROGRAM_PREFIX=before PROGRAM_SUFFIX=after check"
results in the following error (a bug already present before your patch):
gmake -f ./Makefile.bsd CONFIG= check
gmake[1]: Entering directory `/home/sjamaan/src/chicken-core'
cd tests; sh runtests.sh
======================================== compiler tests ...
runtests.sh: ../csc: not found
gmake[1]: *** [check] Error 127
gmake[1]: Leaving directory `/home/sjamaan/src/chicken-core'
gmake: *** [check] Error 2
It should be generating a csc line like this:
compile="../$(PROGRAM_PREFIX)csc($PROGRAM_SUFFIX) -compiler $CHICKEN -v -I..
-L.. -include-path .. -o a.out"
This would cause it to use the "beforecscafter" program.
PS: The README mentions a wiki page that does not exist (anymore):
http://wiki.call-cc.org/cross-compilation
I think that should be http://wiki.call-cc.org/manual/Cross%20development
or http://wiki.call-cc.org/man/4/Cross%20development or maybe it should
just refer to the shipped manual?
PPS: Changing the build system is hairy. Perhaps it's better to
push a release this weekend, and then figure out the proper way
to fix this problem? The disadvantage of that is of course that
this Chicken won't work properly as a cross-compiler. Maybe Mario's
patch should go in as that obviously works for him, and doesn't
break anything that wasn't already broken... Then release and *then*
figure out this mess?
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth