[M3devel] multiple pkg roots

[Jay K]

I believe these two things are highly related.
When you have a multiple pool environment, you must be careful what you replace and in what order. Otherwise you end up with inconsistencies.
 
As well, you possibly need a "runpath" that includes every pool -- i.e. you can't use $ORIGIN, you maybe can, maybe should not use full paths in runpath, probably using an LD_LIBRARY_PATH that shadows the pool list is what people expect.
 
OR, what I described: you don't have any incomplete pools. Every "earlier" pool is initially a copy of any later pool. But then, you don't need any "list" of pools, you just need to create new pools, such as by copying or linking with copy-on-write from an existing pool.
 
I still think there is something to be done here however. I think the initial unshipped output should be in the same or more similar directory structure as a shipped pool/package store/repository.
 
For the outputs -- the .so, .m3x, .m3web, .m3exports files, this seems simple and good. The fact that shipping also copies all the source files however, is a wrinkle. That is, if it were just the output .so, .m3x etc., "correctly" placed 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 sources -- or, do sources not really need to be shipped? One thing I wonder, haven't tracked down, is if sources are shipped because the compiler, i.e. import, needs them, or "only" for debugging? Maybe the .m3x files handle all the import 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 still important. Perhaps perhaps the source should be "shipped" as part of building? You know, they have to be read anyway, so it is not a super wasteful expense. You know, imagine I am in a long edit/compile/test loop, and won't really "ship" till much later -- is it a big waste for "compile" to also copy any changed files to the output directory, even though ultimately they are all dead except for the last version?
 
 
 
I use Reactor briefly years ago, the commercial version. I was not impressed. As I recall it claims to be an "IDE", but lacks an editor and debugger, and maybe more. As I recall it is a custom web server, that you use with any browser, and provides not much more than browsing hyperlinked source code. I will try it again soon.
  Not providing an editor, in retrospect, is probably smart. I was young then and would have tried whatever ideal language oriented editor it came with. Since then I have used the same editor for over 10 years and reasons to change must be /extremely/ strong.
  Not providing a debugger was also probably not a bad decision, given the effort and system-specific work involved, though maybe a gui wrapper over gdb would be good (e.g. Xcode).
 
 
 - Jay


________________________________
> Date: Mon, 6 Jul 2009 20:49:36 -0400
> From: rcolebur at scires.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] multiple pkg roots
>
>
>
>
>
>
>
> From the discussion, it seems to me that we may be mixing two different things. One is how to deal with evolution of CM3 itself where you may need older variant to build newer variant. Using Olaf's "pool" terminology, each variant (version) would be in a different pool I suppose.
>
>
>
> The other concept is that of maintaining one or more "public pools" for use by multiple developers--perhaps aligning pools on project boundaries--i.e. developers on Project A get access to pools A1, A2, ... while developers on Project B get access to pools B1, B2, ... or some such. Plus, also having multiple "private pools" for use by individual developers.
>
>
>
> Not sure I'm understanding exactly what is being proposed, so I welcome you to set me straight.
>
>
>
> Question: Have you used CM3IDE (the old Reactor) and observed how it allows for one "public pool" and multiple "private pools"? It also allows each developer's list of "private pools" to be independent. That is, Developer A's list of "private pools" could be different from Developer B's list. In CM3IDE the term it uses for "pool" is "package root". Each developer is free to adjust his/her list of package roots at any time, though changing the public package root would not make sense unless you had multiple CM3 installations from which to choose.
>
>
>
> Perhaps my understanding of what is meant by "pool" needs clarification?
>
>
>
> Regards,
>
> Randy Coleburn