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). 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? - 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 ------------------------------------------------------------------------------ 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
