[M3devel] package groups question

[Jay K]

I'm sorry but I'm feeling very impatient...
 
 
 
 
> Namely, that "min" is the smallest distribution we plan to make available 
 
 
Ok, that is clearer.
That is not scientific but a matter of a decision.
We could decide that min==std, not a bad decision really, since it gives users fewer confusing choices, and provides one package per platform, with no overlap.
On the downside, it isn't small and some people might say we look fat.




> My "opinion" is that "min" should contain only what is
> necessary for a  working cm3 compiler
 
 
Now you have made a policy decision. An acceptable one.
But not necessarily how it should and not necessarily consistent with some other things.
 
 
> Anything added to "min" that isn't necessary to accomplish
> building the remaining packages would be considered superfluous,
> in my opinion.
 
> Some amount of superfluous on a given platform may be
> tolerable in order to reach consistency among all supported
> platforms regarding the composition of "min". Thus,
> if cm3cg is needed for "min" on some platforms, but not all,
> it is tolerable (IMO) to make it a standard component of "min"
> on all platforms.
 
 
cm3cg doesn't really make sense on NT386 though.
I've probably thrown it in somewhat by accident.
If it is there, it'll depend on Cygwin, and NT386 will just ignore it completely, except for wasted diskspace, network traffic.


> WRT#4, although doc may not be needed to run cm3, it is needed
> for folks to reference and understand cm3.
 
 
Now you are expanding the definition. The documentation is all online too.
I'm certainly fine with including the documentation. Just be clear that "min"'s definition is expanding.
(I'm fine with not distributing min at all, as I said, min==std?)
 
 
> The naive user new to cm3 normally expects to get some documentation.
 
 I don't expect naive users to build cm3 themselves.
 This is in fact a reason not to provide min at all, but std.
 That way, the naive person who thinks he is expert won't make a mistake.
 Really. On the other hand, there are the masochists among us who use the Debian "netinst" and chose no additional packages during setup. :)
If one has the time/patience, it can also be educational to create arbitrary difficult situations and work your way out of them. Really.
(Why does anyone use Linux after all?)
 
 
> If the default is no documentation, how does the poor sap know
> how to get  the documentation and install it?
 
 
Poor saps should use "std", not "min". Right?
What is "min"? The "minimum" distribution that is useful for "everyone" or the minimal distribution to build cm3?
 
 
I should correct myself by the way.
cm3cg is not needed in "min".
It is "easily" just not quickly built from just cm3 and the m3-sys/m3cc part of the tree, and really cm3 is hardly needed for that (but cm3 is definitely needed for building everything else, so needed overall).
 
 
> [Jay] docs/examples I think it was 
> The "typical" installation choice should install it by default.
 
 
"typical" or "min"?
 
 
> WRT#11, now we are finally getting to the meat of my questions. So,
> if I understand you correctly, you are saying that building the "min" 
> group of packages does not recreate for me exactly what
 
 
You must start with a prebuilt compiler (cm3).
Whether you rebuild the compiler or not is somewhat a matter of taste.
Indeed it is more tasteful to build it.
 In which case indeed, you need to build "front", but "front" need not be in the distribution. "front" is in fact basically just cm3, and I think cm3cg.
 
 
Again again again, the "package groups" are just a redundant encoding of the dependency tree that is encoded in the m3makefiles.
We could the entire scripts directory and pretty much everything would work about the same. It would just be a little tedious.
 
 
More and more I think we should actually delete a lot of this.
We should keep the PKGS file, or make cm3 able to figure it out, and the "scripts" should just accept an end goal -- "cm3", and it should read the m3makefiles and build the dependency graph from the buttom up to the goal.
 
 
There could be special goal called "all", AND we could have the broken m3makefiles all filter themselves out.
 
Perhaps a special group called "test", whose membership is implied by path?
 
 
But now, you see, the more of these features I add, the more I'm back to reinventing these minor little scripts and package groups that we have.
 
 
But do you see, that these aren't sort of all that significant?
What you need to build is whatever m3makefiles lists in imports, and follow the transitive closure. And cm3cg is sort of different -- because it isn't a linked/library dependency, but rather because the config files tries to run a program (cm3cg) and that program needs to therefore exist somewhere. That is, the linked/library dependencies are encoded in a nice declarative way in the m3makefiles but the dependency on cm3cg is encoded in an imperative way.
 
 
 
 
My interpretion of "min" has been roughly a minimal distribution that one can start with in order to build cm3, EVEN IF old cm3 cannot build m3core and libm3 from current source. The part I don't understand is that last point -- is it considered a recurring problem? Where is the line? What about sysutils? Is sysutils expected to be forever bound to be buildable by arbitrarily old compilers?
 
 
Do we make a release shortly any such incompatibilities occur?
Do we in fact not cater to such incompatibilities, and "min" therefore does NOT include m3core and libm3?
 
 
Historically there was actually a more recurring problem here, around the list of targets. That is gone now. However there are still occasional problems like LONGINT. It seems to me this is somewhat of a problem of predicting the future, which is impossible. But also taking out very cheap insurance against the only fairly small number of bad futures. That is, throwing in m3core and libm3 is cheap, and it allows for future versions to not be compilable with old cm3, and that not being a big deal.
This is all a bit gray and heuristic however.
 
 
If today you start with a 5.4 or such cm3, indeed, you cannot build m3core and/or libm3. So you need prebuilt 5.4 m3core/libm3.
 
 
If you start with yesterday's cm3 however, you can build today's entire system, without also having yesterday's m3core/libm3 (nor cm3cg).
 
 
See? It depends.
And mitigating the worst case is perhaps worthwhile and cheap.
 
 
And it depends because the system is necessarily circular.
  ("necessary" because the compiler is written in Modula-3) 
Breaking circular dependencies requires cheating.
Changes in circular graphs can require cheating differently.
 
 
 
If we do this, it is probably a good idea to also include sysutils in min.
But it actually goes both ways sort of. That is, if you use old sysutils, then cm3 cannot take a dependency on sysutils changse. But new sysutils can depend on new libm3/m3core. Again, it isn't exactly scientific.
 
 
 
> 
>
> WRT#13, not sure what you mean by "sort of". What are the caveats?

 
I don't remember what I was thinking, but I can tell you that "officially" there is nothing beyond "std". "std" == "all".
Now, actually, we might be missing a few.
"std" is more like everything we know to compile.
For example m3-pkgtools is missing from "std".
But if you get it to compile, we'll add it.
 
 
I believe that is the intent.
Perhaps perhaps perhaps there should be a group called "rare" or "esoteric" and "std" would not include those but all would.
 
 
Actually you know there is a big tension between fine grained decomposition of systems into small testable fast to install pieces, and enabling small systems to be put together, and shipping things separately, vs. larger more monolithic systems which are often easier to reason about because you generally only take a coherent whole and various pieces don't have to adapt to the presence or absence of others, you either have everything or nothing. This leads to bloat, but it does have advantages.
 
 
 - Jay