On Thu, 06 May 2010 16:01:49 -0700, Walter Bright wrote: > Graham Fawcett wrote: >> Simple and well conceived! I would like this for D please (and am >> willing to help :)). > > Any help in this direction will be most appreciated.
I'm slowly working on a proposal, trying to incorporate the feedback we've received on this thread. I've got a few specific questions for the group. (For clarity's sake, I'll refer to downloadable, third-party packages as "subprojects" here, so as not to overload terms like library, module and package. It's not a great name, but it's unambiguous.) Let's say I want to use a subproject in my application: let's take sybrandy's new logging module as an example. Assume I have tool support for declaring my app's dependency on his subproject, and for downloading and storing his source files. It seems to me that a decent tool should not only download the subproject's source, but also compile it into a static library. It should also inform my app's build process, stating what compiler and linker flags I need in order to build and link my app against the subproject. Do you agree that precompiling a subproject is a desirable feature? If so, what's the minimum harnessing we can impose upon a subproject writer, to make their library compilable by an automated tool? We could require, e.g., that the subproject author maintain a Makefile with a 'd-preinstall target, which compiles the package into an installable form (perhaps copying the libfile, along with a link to the root of the sources, into an $INSTALL_TARGET directory). The installer would then finish the installation process. An alternative to 'make d-preinstall' would be a more D-specific package descriptor, like Haskell's ".cabal" descriptors, which tell the installer what the package contains, and how to build and install it. The 'descriptor' approach puts a bigger burden on the design of the install-tool, and loses some flexibility compared with the 'make' approach; but lost flexibility isn't necessarily bad. Given the host of ways that people organize their own code, I don't think we can expect an automated tool to guess the layout and compilation instructions for any arbitrary subproject. I think we either need source layout conventions, or we need a demarcation point like 'make d-preinstall'. Or, what else? Any thoughts? Thanks, Graham
