On 14-Jun-09, at 11:58 PM, Bradley Lucier wrote:
On Jun 14, 2009, at 11:32 PM, Adrien Piérard wrote:
So it doesn't seem like the right solution to package all of these decisions in a single script.
What is the right abstraction?
I guess that the right abstraction is
- conservative: it always works
- end user-oriented: it should work out of the box for those who know
nothing and don't want to know more. A few others will tweak it manually. Most people do *not* need unusual (sic) compiler options, or to select the calling convention.
For some reason I didn't get Marc's reply (I see it on the list archive, though).
Anyone building applications or dynamically-loadable libraries, or calling scheme from C, or ... will have to know *something* beyond
gsc file gsi file
Perhaps the following flags from the makefiles could be exported somehow (have a script that a user can run (in their .bashrc or .cshrc file?) that will add them to one's environment, as GSC_FLAGS_OBJ or something), or perhaps they could just be used in the examples on this list or in the documentation as symbolic variables.
Here's the idea I will implement. Let me know ASAP if you have suggestions.
The gsc compiler will have some new options. Currently there is:
gsc -c foo.scm generate foo.c from foo.scm gsc -link foo.scm generate foo.c and foo_.c from foo.scm gsc -dynamic foo.scm generate foo.o1 from foo.scm
I will add two new options:
gsc -obj foo.scm generate foo.o (or foo.obj) from foo.scm gsc -exe foo.scm generate foo (or foo.exe) from foo.scm
As with the above -c, -link and -dynamic options the name of the file can be chosen with the -o option and C compiler and linker options can be added with the options -cc-options and -ld-options .
The C compiler and linker knowledge will be encapsulated in the gsc- cc.bat script (renamed from gsc-cc-o.bat), which will perform the appropriate action(s) depending on command line arguments and environment variables. With no command line argument the gsc-cc.bat script will dump its knowledge to stdout. The format will be along the lines of:
GSC_CC_COMMAND="gcc -O1 -fwrapv ..." GSC_LINK_COMMAND="ld ..."
That way the user can use this knowledge in his own build procedure, as in
% `gsc-cc.bat` make
There will also be an environment variable GSC_CC_DEBUG which dumps to stdout a trace of the command(s) that the script is executing. So you can do:
% GSC_CC_DEBUG=1 gsc foo.scm
or
% GSC_CC_DEBUG=1 make
One remaining issue... what should be the default gsc option? Currently it is -dynamic, but for consistency with other compilers, and in particular C compilers, perhaps the -exe option should be the default. That way you can do:
% gsc foo.scm % ./foo
and to get a dynamically loadable library you will have to do:
% gsc -dynamic foo.scm % gsi foo
Marc