[Chicken-users] Re: incorrect csc.scm.in assumptions

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> I notice that csc.scm.in has things like %CHICKEN_HOME% in it that are 
> supposed to be substituted.  Makefile.am performs these 
> substitutions.  Do I understand correctly that %SOMETHING% syntax is 
> just there for sed's benefit in Makefile.am, and does not represent 
> some kind of special Chicken syntax to pull values out of the 
> environment or some such?

Upon further investigation: csc.scm.in is designed to work, by default, 
on Windows (!) without modification.  That's what all the %VARIABLES% 
are about.  That way the exceedingly primitive vcbuild.bat can just copy 
and not have to think.  Makefile.am performs sed substitutions on it to 
make it behave otherwise on Unixy systems.  I suppose it is indeed 
reasonable to assume that if you're performing a ./configure with 
Makefile.am, you have a Bourne shell.  In a Cygwin universe you'll even 
keep using Chicken within the Bourne shell; I'm not sure Cygwin stuff 
usually works outside of the Cygwin environment.  However, in a MinGW / 
MSYS universe it is *not* valid to assume a Bourne shell post-build.  
MinGW is typically used to produce native Windows apps.  They could be 
used within the MSYS Bourne shell or on a plain jane Windows command 
line.  In fact the CMake guys tell me that MinGW even changes its 
behavior depending on what shell it is under, or was it mingw-make, I 
forget.  Anyways, some issue there.  The upshot is that MinGW is 
"through the looking glass" and you can't assume shells.

So I'm trying to figure out what catastrophes this causes, during the 
build and otherwise.  And what the solution needs to be.  It is awkward 
to keep 3 different build systems happy.  I am thinking csc should 
decide what shell it's under when it runs, and this means less hardwired 
stuff.


Cheers,
Brandon Van Every