[M3devel] package groups question
Tony Hosking
hosking at cs.purdue.edu
Fri Jul 31 06:28:55 CEST 2009
Randy,
I think this is a very useful exposition of the requirements for
release distributions. I trust that your concerns can be addressed by
Jay and Olaf. I must admit that, at this point, I have lost track of
where things stand in the release installation process and hope soon
to bring myself up to date.
-- Tony
Antony Hosking | Associate Professor | Computer Science | Purdue
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 31 Jul 2009, at 00:14, Randy Coleburn wrote:
> Jay:
>
> Thanks for your reply. I really appreciate your patience in dealing
> with all my questions, especially during this busy time preparing
> for the release.
>
> In response, I offer the following and also ask a few more questions:
>
> My use of the term "minimal" is consistent with what has been
> documented in the working release documentation. Namely, that "min"
> is the smallest distribution we plan to make available, versus "std"
> that contains a "standard" distribution, versus "all" that contains
> everything.
>
> Now as to the exact composition of "min" and "std" that is part of
> my question. I assumed someone (you, Olaf, Tony, ?) has defined
> what these mean. Further, if you look at PkgInfo.txt, it appears
> that these definitions are recorded there, but again back to my
> question as to whether these definitions are accurate, complete,
> what the "cm3 community" wants/expects, and whether my understanding
> of how they are used in the context of cm3 is indeed correct.
>
> I am well-versed in compilers and operating systems principles and
> design, so I don't need a lecture on these fundamentals. My line of
> questioning is concrete with respect to the impending cm3 release.
>
> My use of the term "build" is in the context of "cm3 -build", and to
> be useful, subsequently "cm3 -ship".
>
> As a software/systems engineer, I understand what you mean when you
> say that the code is the documentation when there is no external
> documentation. However, I would hope you agree that no external
> documentation is generally a bad thing. Hence my questions. I'm
> not a python code writer yet, though I'm confident I could be, given
> some time to learn. Thus, I can't presently rely on reading a
> python script as documentation. I am confident that if you, Olaf,
> Tony, or someone can confirm or correct my understanding of what
> I've posed as the way to install the "min" distribution on Windows
> and "build" the rest, that I can and will be able to document this
> process externally for others to review. We can then check scripts
> to see if they deviate from the documentation and make changes (to
> either scripts or documentation) as needed to reflect reality.
>
> You state that I have not defined the "goal." Let me attempt to
> make this obvious. I'm not trying to upset the apple cart here or
> change the way you work to achieve progress/success. My goal simply
> is to "understand" wrt the impending release so I can document, and
> so I can "do the right thing" to make this work correctly on my
> system. We can discuss in the future how things should change for
> the next release.
>
> Thanks for help with my 13-steps. I have some comments and a few
> more questions below.
>
> WRT #1, Yes, I know I may not need all of Visual Studio, but most
> users will just choose the typical installation. If we have
> specific minimums that need to be present, we should identify
> (document) those for users who choose to customize their installation.
>
> WRT #2, you have to start somewhere. If we have both "min" and
> "std" distributions, one can choose which to start with, but your
> discussion of which parts to trim out of "min" should not be left to
> the end user. The release team needs to establish what constitutes
> "min". My "opinion" is that "min" should contain only what is
> necessary for a working cm3 compiler, given the dependency on the
> platform-specific linker. Using "min" one should be able to build
> (cm3 -build -ship) all other packages. 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.
>
> WRT #3, point taken. However, unless we have an easy way to specify
> and checkout only those parts of the tree relevant to a particular
> platform, checking out everything ensures you haven't missed
> something that is going to cause problems later.
>
> WRT#4, although doc may not be needed to run cm3, it is needed for
> folks to reference and understand cm3. This is a long-standing
> gripe of mine that we don't make the installation of doc part of the
> typical installation. The naive user new to cm3 normally expects to
> get some documentation. If the default is no documentation, how
> does the poor sap know how to get the documentation and install it?
> Also, cm3ide, does have links to the doc folder. If you click on
> these links and they are broken, the average user is going to rate
> cm3 as a poor product and move on to something else. Why create a
> problem for the new user? Give him the documentation he needs by
> default and let the expert user remove it if it is unwanted. I know
> that Critical Mass's 4.1 installation put the doc folder there.
> When did someone decide it wasn't appropriate for the default
> installation?
>
> WRT#5, examples is needed for cm3ide. Right now, my bet is that
> most everyone in the cm3 community doesn't know they should copy the
> examples folder to the root of their cm3 installation. That's
> because Reactor wasn't open-sourced until recently as cm3ide. Right
> now the only documentation about this is a README file buried in the
> repository and even that wouldn't be there if I hadn't put it
> there. Again, don't create a problem for the new user. The
> "typical" installation choice should install it by default. Let the
> expert user choose to remove it as part of a custom install if it is
> not wanted.
>
> WRT#6, agree. That's why I wasn't specific on how to do it, but for
> the newbie, it would probably be best to list at least one way.
>
> WRT#7, agree. I was just stating my interpretation of what you had
> communicated to me earlier about setting up config properly.
>
> WRT#8, ok, but you do get an error message if the folder exists
> already.
>
> WRT#9, ditto #7
>
> 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 is
> being published as the "min" distribution. In my view, we have a
> conflict of terminology here that needs to be cleaned up. So what
> exactly is "min" as defined in PkgInfo.txt if it doesn't represent
> the minimal binary install? Furthermore, if I want to use cm3 to
> build the sources for the compiler itself, it would seem from your
> comments that "min" won't do it. Which packages need to built, and
> in what order, to recreate cm3.exe ?
>
> Again you ask about the goal here, so let me be more explicit.
> Given that cm3 continues to evolve and that minimal distributions
> are created at unpredictable intervals, if one wants to ensure the
> cm3 compiler is up-to-date with the latest sources, one would want
> to start with some existing cm3 installation and build and ship the
> compiler's source package(s) along with any other packages where a
> dependency exists. In these instructions, I started with obtaining
> the latest "min" distribution, then grabbed the current source tree,
> so I want to proceed from this point to build a current cm3 compiler
> and any other requisite components to again create a "minimal"
> installation on my platform. From there, one can build some/all of
> the remaining packages.
>
> WRT#12, the repeat is due to my prior understanding. Perhaps this
> is incorrect, or perhaps the recent changes have made this
> unnecessary. But, it seems my understanding of how to rebuild
> cm3.exe is flawed given your response to #11. Are you saying I
> should use "front" to build cm3.exe? Am I the only one to whom all
> this is unclear? Again, we need to document for understanding.
>
> WRT#13, not sure what you mean by "sort of". What are the caveats?
>
> Regarding your comment at the end about scripts, I will respectfully
> choose to disagree with you and hope that we work together to
> improve documentation. After all, if we all get run over by a
> truck, what we know in our brains isn't available to others unless
> we've documented it somewhere.
>
> Thanks for your patience in putting up with all my questions!
> Thanks also for all you are doing for cm3!
>
> Regards,
> Randy Coleburn
>
>>>> Jay K <jay.krell at cornell.edu> 7/30/2009 4:11 PM >>>
>
>
> Randy, the short answer is:
>
> Find a goal state in a graph, which you haven't clearly done, walk
> that graph from the bottom up, and if there are circularities (there
> are, you need to have cm3 first, before you can build cm3), you need
> to download prebuilt files from somewhere (cm3 and mklib).
>
>
> Everything else is filling in the details of the goal state,
> discovering the circularities, and that we have the graph recorded
> in a redundant fashion in pkginfo.txt. The real data is the
> m3makefiles.
>
>
> longer answer:
>
>
>
> Randy, what is a "minimal" distribution? You have't defined the goal.
> What is "build"? You haven't defined the goal.
> I could just say: "Whatever you need, to build it, just download it
> from here."
>
>
> I'll define it as some arbitrary very minimal compiler and runtime
> set, specifically m3core and libm3.
> But you can have working Modula-3 programs certainly without libm3.
> And some Modula-3 programs will have a GUI so will want more
> libraries.
> What is "minimal"?
> And depending on future changes, the steps might change.
> Or maybe just pkginfo.txt will change.
> If there is no documentation and there is code, the code is the
> documentation.
>
>
> A lot of the code is declarative -- you look at the import
> statements in m3makefile.
> For given package foo, say "cm3", you walk the list of imports
> transitively
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090731/32af26a1/attachment-0002.html>
More information about the M3devel
mailing list