[M3devel] new install on Windows Vista

[Jay K]

[keeping you on the thread in case of truncation]
 
 
I would do all the clean each package first,
then build and ship each, two passes over the list
  clean in the first pass
  build and ship in the second
 

That is hard to explain clearly but I think you understand.
 

Given the packages a b c.
 clean a
 clean b
 clean c

 build a
 ship a

 build b
 ship b

 build c
 ship c
 
is what I do, but it should also work as:

 clean a
 build a
 ship a

 clean b
 build b
 ship b

 clean c
 build c
 ship c
 

which is what I think you described.
 

My python files do deal with the config files.
 You might try reading some of it? (not intended rudely, 
  as evidenced by further explanation here) 
 

Here is the current way:
 

 for each file name in 
     cvsroot\m3-sys\cminstall\src\config-no-install
     and cvsroot\m3-sys\cminstall\src\config
  delete corresponding file in \cm3\bin

 That is a "cleanup" step. Not applicable if starting from scratch, harmless.

 mkdir \cm3\bin\config 
 copy cvsroot\m3-sys\cminstall\src\config-no-install \cm3\bin\config

 create \cm3\bin\cm3.cfg with the following exact contents:
  INSTALL_ROOT = path() & "/.."
  include(path() & "/config/" & HOST)

There is no meta syntax there.
  - forward slashes work on Windows 
  - path() is a function that returns the directory of the file calling it 
  - HOST is builtin on newer builds and is a good default for TARGET 
  (We should use this in the distribution archives.) 

Some of this is taste and the system is flexible.

If you wanted, you could put all the files in \cm3\bin, or \whatever.

You can make cm3.cfg look in various places.
  That is what I actually do -- I copy cvsroot\m3-sys\cminstall\src\config-no-install\cm3.cfg
   to \cm3\bin. It ends up picking up %CM3_ROOT%\m3-sys\cminstall\src\config-no-install\TARGET,
   so I can edit just one file while in development and not keep having to copy it around.
   Otherwise I'd get an error in one file in \cm3\bin, fix it, and then remember
   to copy it into the source tree to check it in.
 

> esp. given an aribitrary old minimal installation as a starting point 

 
Yes.
I recently removed a lot of the very old compatibility but I have
used these exact config files with fairly old builds and run upgrade.cmd or upgrade.py.
 

They were meant to work with a wide range of cm3 versions and on
 multiple platforms.

 
If you want I can put the compatibility back.
There were workarounds for bugs, not yet provided features, etc.
 
 
The workarounds dynamically adapted to what capabilities the cm3/cm3cg
they were using had, and they new for newer platforms to just assume
things work well. There are more newer platforms than older platforms
so it was kind of annoying to carry it all around, but it does work.
I can put it back.
 

You might also want to read README.jay that I checked in.
 

I'll summarize it here:
 

create new empty directory, and bin and bin\config thereof.
Put cm3 and cm3cg in bin, copy all the config files to bin\config,
create cm3.cfg as shown earlier.
 

Given a recent cm3 (e.g. one that supports LONGINT) that is all you need
to build the system starting with import-libs or m3core and on up.
 

(import-libs is almost unnecessary. It is a workaround for that
 - older cm3 builds contained bogus files
 - some but very few native toolsets don't have the requisite files,
   like Visual C++ 2003 Express
If you have a decent toolset and start with an old cm3, you can just delete
the toplevel lib directory to get started and skip import-libs..but it builds
super fast anyway).

 
You don't likely even need cm3cg, it just saves time.
And you don't need it on NT386 of course.
 

If you have too old of a cm3, then you start with cm3 and pkg\m3core and pkg\libm3,
and start with import-libs and sysutils, skipping m3core and libm3.
 

(I'm assuming both m3core and libm3 use LONGINT, if they don't, then..)
 

Oh, also older and even current cm3 can't build certain versions of m3core and/or libm3 (I think just libm3) between old and present due to the platform list. But current m3core and libm3 don't have that problem.
 

m3-sys\cminstall\src\config is dead, as are all the config files around
m3-sys\cm3\config.
 

I deleted m3-sys\cm3\config but Tony added some back.
 

I'm trying to wait until after this release to delete a lot of the dead stuff.
Trying also to consider if some of it has historical/reference value.
Like all the Unix *.i3 files. Maybe just comment those all out instead of deleting them.
I know there is CVS history but it much easier to see what is dead and present
than dead and gone, as long as there are good hints that it is dead, like commenting
out every line.
 

"a lot has changed in the config files since 5.8.1" I imagine would be
  - removal of compatibility stuff
  - possibly the use of symlinks and removal of hardlinks 
  - having make_lib call skip_lib 
  - oh, right, refactoring of all the toplevel files to include(architecture) and include(os).
     That had been bugging me for a long time so I finally did it.
    Basically the original authors of the config files either
     - liked monolithic files
     - didn't consider the proliferation of OS across multiple/many architectures
     These days we have fairly few OS, but many OS x architecture.
      NetBSD on everything, Linux on everything, everything else still on a few
 

 Let me know if that doesn't answer everything or if you have further questions.
 

 Once I have the Tinderbox runs running better on Posix sysetms, I will face the choice for    NT386 of using Cygwin sh to drive it all, or
   rewriting all the .sh in .cmd or .py or .js. I'm strongly considering rewriting in .py. Rewriting is also a good way to gain understanding, you have to read and understand every line.
 
 
 - Jay


________________________________
> Date: Mon, 27 Jul 2009 23:24:26 -0400
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] new install on Windows Vista
>
>
>
>
>
>
>
> Jay:
>
>
>
> I am attempting a new install on Windows Vista. I have a question about the config files.
>
>
>
> I downloaded your minimal d5.8.1 archive at: http://modula3.elegosoft.com/cm3//uploaded-archives/cm3-min-NT386-d5.8.1.zip
>
>
>
> It is unzipped to C:\cm3. Note that I also have a complete checkout of the current cm3 tree (HEAD branch) in C:\cm3\Sandbox. I've also installed Visual C++ 2008 Express.
>
>
>
> My plan is to put "C:\cm3\bin" on my path. Then, use my "C:\cm3\Sandbox\scripts\win\do-cm3.cmd" script to build everything, hoping that this will indeed upgrade the compiler in the proper order, based on PkgInfo.txt. If I invoke my script as follows "do-cm3 all clean buildship" it will apply the "cm3 -clean", "cm3 -build", and "cm3 -ship" command sequence to each package identified in PkgInfo.txt in the order the packages appear in PkgInfo.txt.
>
>
>
> Perhaps this is a flawed plan; if so, let me know. I know there are various scripts and python that may already purport to do what I want to do, but please humor me. I am trying to learn the actual low-level steps required to do the install and upgrade, beginning with the minimal distribution. In my view, once I have the minimal binary distro plus the new sources, I ought to be able to use the cm3 commands (perhaps scripted) to rebuild everything properly, as long as I do it in the correct order.
>
>
>
> Now, on to my question. I see your minimal archive has a "C:\cm3\bin\cm3.cfg" file and a "C:\cm3\bin\config" folder. I know that in "C:\Sandbox\m3-sys\cminstall\src" we have a config folder and a config-no-install folder. In the past, I've been copying the contents of the config-no-install folder to "C:\cm3\bin". (1) Is this correct? If not, please explain.
>
>
>
> (2) Should the d5.8.1 "C:\cm3\bin\config" folder be deleted? If not, how/when/should this folder be updated?
>
>
>
> (3) Looking at the cm3.cfg et al from d5.8.1 and comparing to now, it seems a lot has changed, hence my questions. I also wonder that if someone used the python or other scripts, do these handle updating the various config stuff, esp. given an aribitrary old minimal installation as a starting point?
>
>
>
> Thanks for your help!
>
>
>
> Regards,
>
> Randy Coleburn