[M3devel] multiple pkg roots

[Jay K]

Mostly agreed.
It's just, you know, there is a contradiction between
 "making ship just a recursive copy or link"
 and 
 "not wastefully copying files" 
 
 
Given that files would only be copied when they change, and when they change they have to read anyway, maybe it's not so bad.
 
 
The dilemna is whether or not "build" copies the sources, so that ship is just recursive copy/link, or if build shouldn't waste time doing so and ship would continue to do all/some directory layout changes.
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 6 Jul 2009 23:54:58 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] multiple pkg roots
>
> Jay K writes:
>>
>>a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" pla
>>ced upon output, then ship would just be a recursive copy, or move, or change
>>the root. However "ship" remains "complicated" due to the "need" to ship the s
>>ources -- or, do sources not really need to be shipped? One thing I wonder, ha
>>ven't tracked down, is if sources are shipped because the compiler, i.e. impor
>>t, needs them, or "only" for debugging? Maybe the .m3x files handle all the im
>>port needs, and the .i3 files are never reparsed? Still, surely the source .ig
>> files are shipped because they might be needed. And "only" for debugging is s
>>till important. Perhaps perhaps the source should be "shipped" as part of buil
>>ding? You know, they have to be read anyway, so it is not a super wasteful exp
>>ense. You know, imagine I am in a long edit/compile/test loop, and won't reall
>>y "ship" till much later -- is it a big waste for "compile" to also copy any c
>>hanged files to the output directory, even though ultimately they are all dead
>> except for the last version?
>
> Isn't the main purpose of any programming language that it is used
> for human-to-human communication?
>
> The .i3s need to be shipped so that programmers can see the interface
> of the libraries they are using, whether it be for debugging or
> initial development. That also means they should be shipped precisely
> when the binaries are shipped (they have to remain synchronized).
> Things would get extremely confusing if sources (I'd prefer to call
> them "interfaces"---you don't have to ship the "implementation
> modules") and binaries are shipped at different times.
>
> Mika