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

[Jacob Carlborg]

On 5/14/10 22:27, Graham Fawcett wrote:
> Hey again,
>
> On Thu, 13 May 2010 18:26:07 +0000, Graham Fawcett wrote:
>
>> Hi BCS,
>>
>> On Thu, 13 May 2010 17:31:34 +0000, BCS wrote:
>>
>>>> (b) derives the list of files by including all *.d files, except those
>>>> in directories named 'test' and except those which contain a main()
>>>> function.
>>>
>>> I'm thinking of how to make this work for the simple publication model
>>> of "Put it all out via HTTP/SVN/CVS/GIT/etc.". Anything that works for
>>> that should generalize well.
>>
>> Yes, agreed, 'simple publication' is what I hope to target. I'm
>> confident that issues like versioning, dependencies, and cataloguing can
>> be addressed once 'simple publication' is stable.
>>
>>> How about: Download files as needed to do imports from any local code
>>> but don't build them. Once you have copies of everything you need,
>>> build one lib per mapping rule that includes everything retrieved via
>>> that rule. At that point the name doesn't hardly matter at all. You can
>>> make it the FQN of the mapped package if you want it easy to interpret.
>>
>> If I follow you, then the naming of libraries (or pre-compilation of
>> libraries at all) is a non-issue: we download the necessary source
>> files, cherry-pick the ones needed for our project, and compile them
>> together. Or let the compiler do the cherry-picking for us: just make
>> sure everything is "included" properly when we invoke the compiler, and
>> it can discover all the necessary modules.
>>
>> I have a prototype that does roughly that already, but I was concerned
>> others might think the lack of a pre-compiled library was too hackish
>> (though I quite like it!). I think I'll proceed, and come back with some
>> sample code.
>
> OK, I'm back. :) I've put a copy of my prototype, here:
>
> http://github.com/gmfawcett/d-build
>
> The name 'd-build' is a bit misleading, but I have nothing better to
> call it.
>
> Currently it's a Python script -- sorry, I can still prototype a lot
> faster in Python -- but a D version will follow if there is interest.
>
> If you're interested, please visit the github link and read the README
> to get an idea of what it does (and doesn't do). If you look at the
> DEPS file, you'll see the amazing way that I specify a dependency on a
> specific verision of an external project.
>
> At this point, it's so simple that it's almost a "so what" -- but I
> think it is a promising start. Once the mechanics are down pat, the
> fun begins.
>
> Best,
> Graham

If you already have it written the script in python why do you use a 
shell script as the dependency file? You could use python for that as 
well and you wouldn't have problems on windows.