On Wed, Mar 28, 2012 at 1:23 AM, Jean-Philippe Bernardy <berna...@chalmers.se> wrote: > I'll just throw my two cents. > > I am not sure what are your goals, but my main issue with developing > was the time it took to compile the sources. I think at the moment > "cabal install" compile (nearly) every module twice. This should be > avoidable by using the new cabal functionality to depend on a library > built in the same cabal package.
I'll look into using that feature: http://factisresearch.blogspot.com/2010/08/speeding-up-your-cabal-builds.html My overarching goal is to reduce the development cycle. Reducing the compile time for the executable would contribute. My thinking is that the requirement for yi to be built into a library can be removed. Instead the custom yi could be compiled with the Yi module source directory being in it's include path. The custom yi compile would not need yi to be built as a library and would only compile the modules needed. This would avoid unnecessary compilation of Yi modules. For instance: the vim keymap for a emacs keymap user. The cabal step of packaging up the compiled modules into a library and installing the library would also be eliminated. 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
