[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: |
Mario Domenech Goulart |
Subject: |
Re: [Chicken-hackers] [PATCH] When referencing libchicken, take PROGRAM_PREFIX into account |
Date: |
Thu, 17 May 2012 08:27:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) |
Hi,
Thanks for looking at that, Peter. Some comments below.
On Thu, 17 May 2012 13:41:19 +0200 Peter Bex <address@hidden> wrote:
> On Wed, May 16, 2012 at 02:12:30PM -0400, Mario Domenech Goulart wrote:
>
>> 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).
Indeed. I overlooked PROGRAM_SUFFIX. I'll try to provide a patch which
also takes PROGRAM_SUFFIX into account.
> 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?
I'm not sure about this part. I suppose tool names built for the target
don't support prefixing/suffixing.
>> 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.
If that fixes the problem, it doesn't sound too complicated (hairy
problems always start with a sentence like that :-)).
> 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?
It seems that master's README doesn't reference that page anymore. Are
you looking at a README from some tarball (4.7.4 does mention the page
that doesn't exist)?
> 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?
Your plan sounds good to me. I can try to provide a patch to handle
PROGRAM_SUFFIX too, so prefixing/suffixing would be supported for the
cross compiler, but not for the native and target compilers.
Best wishes.
Mario
--
http://parenteses.org/mario