Experimentation with that idea and the use of the "strings" command suggest that the full path to the ghc binary is used and is stored in the compiled Yi executable.
I'd rather not replace the ghc binary with a shell script that determines if it's being called by Yi or not and then behaves differently. While amusing, I'd rather not.
On Tue, Jun 21, 2011 at 11:59 PM, Alex Rozenshteyn <rpglover64@gmail.com> wrote:You may be able to create a 'ghc' shell script that invokes (the
> From looking at Yi's code, there seems to be a hard-coded list of arguments
> to pass to ghc. A hack would be to recompile Yi with the arguments to use a
> different package database...
real) ghc with the correct --package-conf for Yi, then make a Yi
script that sets up a custom path so that it finds your ghc script
first. Lots of "ifs", but at least you wouldn't have to maintain a Yi
fork :)
--Rogan
>
> On Wed, Jun 22, 2011 at 2:32 AM, Rogan Creswick <creswick@gmail.com> wrote:
>>
>> On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn <rpglover64@gmail.com>
>> wrote:
>> > More precisely, I'm trying to run yi in its own sandbox, created by
>> > cabal-dev.
>> >
>> > yi uses dyre to recompile its config file. Unsurprisingly, this fails,
>> > since
>> > ghc doesn't know anything about the yi install unless pointed to a
>> > separate
>> > package database.
>>
>> I'm not familiar with dyre, is there any way to tell it to use a
>> specific package database? That *sounds* like it's the problem (since
>> that's the bulk of what cabal-dev does... it establishes a fresh
>> package db and hides the user db).
>>
>> --Rogan
>>
>> >
>> > Has anyone gotten a similar setup to work, or does anyone have any
>> > suggestions?
>> >
>> > --
>> > Alex R
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>
>
>
> --
> Alex R
>