[M3devel] package groups question

[Tony Hosking]

I don't care if future versions are not compilable with old cm3.  But,  
vice versa, old versions should always be compilable with new cm3.

My gut feelings run along the lines of what Randy has said.  I do  
think that the average user should accept std as the install, while  
min is for power-users who know what they are doing. Does that jive  
with other people's expectations?

On 31 Jul 2009, at 03:39, Jay K wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090731/bd22f3f4/attachment-0002.html>