[M3devel] multiple pkg roots

[Olaf Wagner]

Just some short comments from me before I leave you again for a while:

  o My suggestion of using multiple pools is just a generalization
    of the existing PKGROOT concept. It's intended to better support
    project and team setups in software development. There was no
    intention to use this to support `CM3 evolution' as Randy calls it
    (though it could be used for it).

  o I would not like to restrict the concept to two pools or levels.

  o For a first step, I'd suggest to keep thing really simple:
    - make cm3 understand a CM3_POOL_PATH to satisfy imports
    - only ship to the leftmost pool in the path
    - mark the hierarchy level in the pools (e.g. 0: system global,
      1: project level, 2: individual workspace level)
    - disallow shipping when packages from lower pools than the one
      shipped to are referenced

    This way, there is no explicit promote operation (that can be added
    later), but we should be able to keep the dependencies correct easily.
    (I haven't thought this through completely though, so I may be
    mistaken.)

    I just realize that this might not be correct though: if a library
    package is locally modified and tested in a local pool, we'd probably
    like the other importers in the global pool to use our new dependency,
    too, or we'd end up with two versions of the same library in our
    program, which would probably neither work (names clashes) nor be what
    we intended: so we'd have to teach cm3 to detect those `invalid'
    importers and forbid us to use them. I.e. modifying a base library
    would require us to recompile (and probably adapt) all depending
    packages. It seems that all this needs more and careful consideration...

  o I also strongly suggest to postpone all this until we've finished the
    current release.

Olaf

Quoting Jay K <jay.krell at cornell.edu>:

>
> 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



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194