chicken-hackers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]