Building subprojects (Re: envy for "Writing Go Packages")

[Graham Fawcett]

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