Re: [Chicken-users] Extension loading problems in CMake/MinGW csi binary

[Brandon J. Van Every]

Ian Oversby wrote:
> Could it be worth hacking chicken to output where it is looking for 
> the files when requiring the extensions maybe?

What's worth it, is understanding how quotes are used in that context.  
That's probably the problem.

> Okay, glancing at the make log, I can believe the srfis have been 
> built in (pity it doesn't retain the commands executed for actual 
> compilation)...

All the Makefiles are in CMakeFiles/targetname.dir/build.make and so 
forth.  You can always diagnose what's actually going on in a CMake 
generated build by poking around in there.  Often I've compared results 
with the ./configure generated Makefile to deduce what's wrong.  Also 
you can use "make VERBOSE=1"


> and also looking at the CMake generated makefiles leads me to believe 
> I won't find anything of help there :-/  

Possibly you only looked at the toplevel Makefile.  The meat is down in 
the build.make files.

> Hmmm, what do you mean by "quoting problem", maybe I can look into that?

There's this obnoxious set of substitutions required for 
chicken-defaults.h.in and csc.scm.in, delimited by % %.  
chicken-defaults.replace.cmake and csc.replace.cmake are CMake scripts 
that perform the necessary substitutions.  The various INSTALL_* 
variables denote pathnames.  Windows pathnames can have spaces in them, 
and passing them around between the scripts and to various compiler 
stages is driving me nuts.  I do not know what's supposed to happen or 
if I've done the right thing.  Basically I pursued trial and error until 
the damn thing built, and it took forever.  If I come to understand this 
stuff, and find a way to eliminate it, I will, because there is nothing 
more hideous than double secret quoting escape problems.  Well, 
excepting generalized regex programming, or obfuscated programming 
languages, but those are other rants.

For all I know, there might be nothing wrong with my quoting, and the 
real issue may be lack of pathname-with-spaces support.  Yes, Windows 
does take pathnames in double quotes.  Now try quoting and escaping the 
quotes to get 'em through the C preprocessor, or through Chicken.

On the way to salvation, I've removed the bletcherous hack known as 
vars.cmake.in.  The method of passing arguments to the substitution 
scripts is now much more straightforward.  Pull from Darcs.


Cheers,
Brandon Van Every