On Wed, Mar 28, 2012 at 11:02 PM, Corey O'Connor <coreyocon...@gmail.com> wrote: > 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.
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. > > 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
