On Thu, Mar 29, 2012 at 1:36 PM, Corey O'Connor <coreyocon...@gmail.com> wrote: > On Thu, Mar 29, 2012 at 7:53 AM, Jeremy Wall <jw...@google.com> wrote: >> I would add that making the build cabal-dev friendly as well would be >> a good idea. >> >> Having yi-contrib and yi be separate build makes compiling both with >> cabal-dev less >> easy than it could be. > > I haven't used cabal-dev. What problems do you encounter?
Since cabal-dev compiles everything in a clean environment you have to pass some commandline flags to the commands or it recompiles yi every time. Not a big deal but perhaps a top level cabal config so you can build it all at one go? > > I though cabal-dev auto-magically handled one package depending on the > source (not installed package) of another package? > > If custom yi was compiled given the Yi module source directory instead > of the yi library yi-contrib *could* be safely folded back into yi. > Unless a user imports a module into their config the module would not > need to be compiled. > > Cheers, > Corey > >>>> On Wed, Mar 28, 2012 at 3:32 AM, Corey O'Connor <coreyocon...@gmail.com> >>>> wrote: >>>>> I have been considering how to improve the developer experience. The >>>>> goal is to make the compile/test cycle shorter. There are a lot of way >>>>> to do this. However I'm thinking of going a bit nuts and integrating >>>>> the process into yi itself. Code on Yi directly from within Yi and >>>>> have the re-config process automagically incorporate the changes. >>>>> >>>>> Sounds like hacker mode huh? Very similar. WE just need to remove the >>>>> hack! >>>>> >>>>> I would like to consider changing the system such that: >>>>> * yi, the executable, does *not* contain the full yi library. The yi >>>>> executable would be responsible for compiling the users config in an >>>>> environment that exposes the appropriate Yi modules and dependent >>>>> packages. >>>>> * The Yi modules would always reside in a git clone. The yi executable >>>>> would know where this git clone resides on disk. Either the system >>>>> running yi would have a yi clone in a shared location OR the user has >>>>> their own yi repo clone OR yi checks out a new clone. >>>>> * On reconfigure the yi executable would: take the serialized out >>>>> state of Yi, run the recompile and either: Resume the yi that >>>>> initiated the reconfigure to present errors; Or start a new yi-custom >>>>> with the serialized state. >>>>> * The yi executables dependencies would match the base dependencies of >>>>> the yi library. When the yi executable is installed it would retain >>>>> the versions of the libraries it was compiled against. This would form >>>>> the environment that the custom yi would be compiled under. >>>>> >>>>> Optionally, the yi executable can compile a set of Yis that use some >>>>> pre-defined configs. Such as a yi-emacs and yi-vim etc. Which could be >>>>> used to install a system-wide yi version that requires no setup by the >>>>> user. >>>>> >>>>> Ideas? Thoughts? Yah/neh? >>>>> >>>>> -Corey O'Connor >>>>> coreyocon...@gmail.com >>>>> http://corebotllc.com/ >>>>> >>>>> -- >>>>> Yi development mailing list >>>>> yi-devel@googlegroups.com >>>>> http://groups.google.com/group/yi-devel >>>> >>>> -- >>>> Yi development mailing list >>>> yi-devel@googlegroups.com >>>> http://groups.google.com/group/yi-devel >>> >>> -- >>> Yi development mailing list >>> yi-devel@googlegroups.com >>> http://groups.google.com/group/yi-devel >> >> -- >> Yi development mailing list >> yi-devel@googlegroups.com >> http://groups.google.com/group/yi-devel > > -- > Yi development mailing list > yi-devel@googlegroups.com > http://groups.google.com/group/yi-devel -- Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel
