<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16825" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>Of course, there are platforms that don't use etc, like Windows.</DIV>
<DIV> </DIV>
<DIV>I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements.</DIV>
<DIV> </DIV>
<DIV>On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3".</DIV>
<DIV> </DIV>
<DIV>Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support?</DIV>
<DIV> </DIV>
<DIV>Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files.</DIV>
<DIV> </DIV>
<DIV><STRONG><U>My 2 cents</U></STRONG>: Whatever is decided, we need to <U>document</U> it, and make it <U>widely known</U> (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Olaf Wagner <wagner@elegosoft.com> 5/28/2009 2:44 AM >>><BR>Quoting Tony Hosking <hosking@cs.purdue.edu>:<BR><BR>> Again, I don't see why the config file should be thought of as<BR>> something that users should edit. It is specific to a given<BR>> installation, not to configuration of the packages after installation.<BR><BR>I'd second that, too, but then almost all software configuration files<BR>living in .../etc on Unix systems should not be edited by ordinary<BR>users. They're there so that the software can be adapted to different<BR>system setups and conventions, that is, they should and must be edited<BR>by the system administrator. I think this is true for at least the<BR>part that defines the global paths used by the installation:<BR>PKG_INSTALL, BIN_INSTALL, PKG_USE, etc.<BR><BR>It is criticised, if I understand it correctly, that CM3 is not flexible<BR>enough in allowing this kind of customization currently. And that we<BR>do not comply to the file system hierarchy standards. Moving (part of)<BR>our config files into some etc directory would be a step into this<BR>direction.<BR><BR>Olaf<BR><BR>> On 28 May 2009, at 16:34, Olaf Wagner wrote:<BR>><BR>>> Quoting hendrik@topoi.pooq.com:<BR>>><BR>>>> On Wed, May 27, 2009 at 08:57:27AM +0200, Olaf Wagner wrote:<BR>>>>><BR>>>>> 2. Actually move the default for configuration files to cm3/etc,<BR>>>><BR>>>> Debian may well insist that configuration files be in /etc/cm3.<BR>>><BR>>> Understood. I'd think that something like<BR>>><BR>>> $ORIGIN/../etc/cm3.cfg:$ORIGIN/cm3.cfg:/usr/local/etc:/usr/etc<BR>>><BR>>> as a default may be reasonable. For more exotic setups, the<BR>>> binaries must either be recompiled or the environment variable<BR>>> M3CONFIG must be used.<BR>>><BR>>>>> though I objected that change for this release previously. But it won't<BR>>>>> get easier if we wait, and I think we can built in some backward<BR>>>>> compatibility that should help during the migration. It will take some<BR>>>>> more time though.<BR>>>><BR>>>> -- hendrik<BR>>>><BR>>>><BR>>><BR>>><BR>>><BR>>> -- <BR>>> Olaf Wagner -- elego Software Solutions GmbH<BR>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>>> <A href="http://www.elegosoft.com">http://www.elegosoft.com</A> | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>>><BR><BR><BR><BR>-- <BR>Olaf Wagner -- elego Software Solutions GmbH<BR> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR> <A href="http://www.elegosoft.com">http://www.elegosoft.com</A> | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR><BR><BR></DIV></BODY></HTML>