gambit-scheme doesn't use correct compiler after installed

[eraserhd]

gambit-scheme needs to refer to the compiler that built it after it's installed. This seems impossible the way homebrew is designed right now. The formula has no access to real compilers (and therefore configures compile flags in a very strange way that works for neither clang nor gcc), and either clang or gcc is used.

This is when installed with --use-gcc.

It encodes the compiler into the gambc-cc script. Manually changing it to gcc 4.2.1 produces warnings because flags were detected incorrectly.

[adamv]

Does it work with --env=std? What OS version are you on?

[eraserhd]

I'm on mountain lion, and I have no idea where I would put --env=std. For example, compiling a file is:

gsc -exe foo

Like, maybe,

gsc -exe -cc-options '--env=std'

?

[adamv]

brew install gambit-scheme --env=std and then see if it wrote out the compiler files correctly.

[eraserhd]

That works and detects the correct gcc. Is there a way to get the formula to do something like that when --use-gcc is passed? Or should this just be documented?

[adamv]

We can add env :std to the formula to force this behavior; a comment should be added above it explaining why it is there.

The default env is called "superenv", and uses tricks to force our use of compiler+flags through any binary invocation, which is what is confusing GS here.

[eraserhd]

OK, I'll make a pull request. I think this is wise because using gambit
becomes painful for any useful size program when it compiles with clang.
(Exponential compile time based on source size.)

On Tue, Jan 15, 2013 at 3:21 PM, Adam Vandenberg
notifications@github.comwrote:

We can add env :std to the formula to force this behavior; a comment
should be added above it explaining why it is there.

The default env is called "superenv", and uses tricks to force our use of
compiler+flags through any binary invocation, which is what is confusing GS
here.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17099#issuecomment-12287099.