On Thu, Mar 6, 2014 at 2:53 PM, Antti Kantee <[email protected]> wrote: > On 06/03/14 14:06, Justin Cormack wrote: >>> Now, questions: >>> should this be the default mode of operation? In other words, should we >>> use this for the automated tests and docs? >> >> Sounds tidier. >> >> i don't think I would be inclined to use it for the tests, but >> probably would for the docs. Test machines might not have bash >> installed, and then the tests document what is going on, while the >> docs are more readable. > > Probably the only thing that will work differently on a non-bash bourne > shell is that prompt will be 'rumprun ($RUMP_SERVER)$ ', and we won't > see that in the tests anyway. I can test it later when I find a > non-bash sh from somewhere).
ok. Actually ash works fine and does replace the vars (thats the default shell in Debian). > IMO we should test what we tell the users is going to work. Also, we > can run the tests with "set -x" if you want a log of what's going on -- > but I do like the current quietness. > >>> What should the relationship of rumprun and rumpremote be? It seems to >>> be like they're completely different animals. Should there be two >>> separate builds? For one, rumpremote doesn't require building the >>> kernel components. Also, the above type wrapper for rumprun is only >>> available e.g. via the Lua console, and cannot be implemented using a shell. >> >> If you can make a simpler build that is quicker and only builds >> rumpremote then we could make that the default and use for all the >> tests. I have some use cases for rumprun, but can always fork it... > > Well, hmm, the tests do need the kernel side. So I guess at least the > tests would need to build the kernel portions -- I don't think we can > quite go binary just yet. > > I'd also like to see the package eventually becoming installable. Which > means cleaning up the mess I've made in the Makefile (should never write > Makefiles with the assumption that someone who like build systems is > going to fix them later). But what about we pencil down that we're > going to install everything into $PREFIX/lib/rumprun, with the hierarchy > being: > > rumprun/bin/ > rumpremote wrappers > rumprun/lib/ > .so's PLUS librumpclient > rumprun/internal/ > rumpremote, rumprun, rumprun.lua > > So rumprun would still work, just need to set LD_LIBRARY_PATH (and > LD_DYNAMIC_WEAK). The wrappers would just work after you source the env > file (which is why we need a known location for librumpclient). > > Seem ok? yes. Thats everything except rumpremote.bash which not quite sure where you would install - its not an executable... > - antti > > *) I do have two changes I want to make, but given it's been several > years, not sure if those are going to happen soon To what? ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
