2009/11/2 Michael Homer <mich...@gobolinux.org>: > On Monday 02 November 2009 21:31:35 m...@svn.gobolinux.org wrote: >> Author: mwh >> Date: 2009-11-02 00:31:35 -0800 (Mon, 02 Nov 2009) >> New Revision: 4110 >> >> Added: >> trunk/Scripts/bin/Alien-LuaRocks >> Log: >> Add Alien-LuaRocks script, implementing the Aliens interface. >> >> This script gives an example of the proposed interface and has been >> written for clarity in that mor than for any other goal. It is likely >> that the final interface script will be in Lua and access the LuaRocks >> database directly, rather than parsing the output of the command-line >> tool. The same interface is proposed for every wrapper of an alien >> package manager. >> >> This script does not support installing yet, and does not specifically >> use the /System/Aliens tree nor create the /S/A/LuaRocks hierarchy. > I would like feedback on this series (back to r4108). This is how I intend to > build the /S/A system in terms of interface, calling out to external wrappers > for each alien type. The wrappers could be anything executable, but this > sample one is a basic shell script wrapping the command and parsing its > output. The interface arguments are at the bottom of this script. > I'd prefer a library interface, like BuildType_foo, with a well specified API, much like the one you have now, e.g. LuaRocks_getversion(). It just feels cleaner. Otoh I can understand that using wrappers and keeping is sh-compatible is better if we want portability and adaption by others.
> The changes committed to date do not include installing, and do not include > anything to support the backend changes in the various languages to set their > search paths appropriately. It also does not handle any reverse dependencies > (Ruby-GTK+ depends on GTK+, etc). Install support only requires an extension > to the interface and a couple of insertions at the beginning of Compile and > InstallPackage. Installation should be a transparent process to the user. > What do you mean by reverse dependencies? "Normal" dependencies? And, yes, transparency is desirable. > > There's a bit more to go before this is ready for wider use, and once the > interfaces are stable we will need to start collecting the wrappers and > updating the language recipes to have the right search paths, but this gives a > reasonable picture of where it's all going. I like it (but you already knew that :) ) -- /Jonas _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
