[M3devel] It works! (was: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110)

[Jay K]

"Yes".
 

1)
"config"'s user configurability is over-implied imho.
It shouldn't all be considered config.
It needs refactoring into bin and config.
Possibly rewriting the stuff that has stood the test of a few year's time into
native Modula-3.
 

It used to be worse.
Each file used to be standalone.
I refactored -- all the "common" files.

 
I think it is partly called config because if you look at the
gcc source tree, it also has a config directory.
https://github.com/modula3/cm3/tree/master/m3-sys/m3cc/gcc/gcc/config
 

It should be called "target" perhaps.
Heck, we could have bin/<target>/cm3cg, bin/<target>/cm3.cfg or bin</target>/config.quake or such.
 

Consider all the Perl and Python and sh you may or may not have in /usr/bin.
Is it configurable? User editable? Maybe/kinda.
 

Consider that /etc is often sh snippets.
 

The line between code and data is somewhat blurry, and I am somewhat lazy.

 
We could split the files into "less editable" and "more editable".
 

The bulk of the text in the files is hard to understand and hard to edit.
 

And then there is the question of updating. And when I make edits
to "the defaults", which do I assume are carried with cm3, vs. which
do I assume an update will leave alone?

 
Basically, I'm lazy, and haven't perfectly evaluated or factored everything.

 
It used to be worse.
However, there is/was cminstall, which the user is/was meant to run
which would edit small parts.
 

So maybe those very parts should be broken out into separate files?
 

There another problem though.
Which parts of "config"/cminstall need to be rerun when something else changes?

 
You know, imagine I install cm3 and then I install X Windows.
Installing X  Windows implies a need to reconfigure.
The full needs of a configuration system are related to a packaging system.
Debian I believe handles this all well, after years of development focusing
on these sorts of things.

 
And then we'd have to handle all the other packaging systems.
 

And nobody has been interested/motivated enough so far to really
integrate so well into all the various packaging systems.
 

But also, we target not just Unix.
Yet we have almost the same directory structure on Unix and Windows.
The difference is that on Windows we put the .dlls in bin.

 
 Should we use $HOME/etc or $HOME/config?
 And have /usr/local/cm3/bin probe around? I think I did put in some probing.

 
To what extend do users just have private installs $HOME/cm3/bin
vs. sharing binaries and having just split off config?
 

What if they want to change the compiled code?
 

To what extent are systems multi-user?
 

So "yes" there is work to do here and we need help :)
 

2)
Yes. Remember how I said I was lazy and made just one, or rather two,
package sets? That is what you are seeing here.
 
Olaf did put more thought/work into this and the .sh files do build a few different distribution sets.
 

3) I think so. Look for "www" in config?
 
 
1-3) yes.
In particular, are you aware of the rpath/origin/relink-upon-make-install/LD_LIBRARY_PATH situation?

 
I went with origin.
I didn't have the energy or perhaps the buy-in to implement relink-upon-install approach.

 
Previously we relied on either paths being correct *before* make install, or setting LD_LIBRARY_PATH.
Both are bad solutions.
There are I believe approx. 4 choices, for redistributable binaries that might go to a variety of setups:
 

 a) paths correct on original build machine 
 b) LD_LIBARY_PATH  
 c) origin 
 d) relink upon install (leaving binaries not further relocatable by mv/cp). 
I went with c.
So if you move samples around, you have to deal with that.
bin/samples would seem easy enough though.
 

Or heck, a peer of bin? lib? samplebin? samples?
 

I think if we adopted automake/libtool, we'd get #c and it would be kinda good.
Do cmake users use libtool?
 

You know meta meta meta point -- we have our own little close to state of the art
build system, but not quite state of the art. It works prety well and pretty portably.
But not always as well as people would like.
 

Between autoconf and Perl's method of port to every system, we are more like Perl,
but also trying to find least common denominators that don't actually have to be ported.
 

Does this make some sense?
 
 
4)

Just command line parsing in make-dist.py.
 

5) yes
 
 
6) I don't understand.
min is meant to be:
 6a) a minimal toolset
 You can write hello world.
 cm3, cm3cg, mklib, config, m3core, libm3 
 text, threads
 not a gui  
 This is subjective. The "resource" stuff should probably be here.
 

 6b) It is meant to be enough to bootstrap another cm3 version from,
 older or newer. cm3 manages its dependencies carefully.
 It either carries things itself, or they are in min.
 For example, it doesn't use X Windows (or .i3 files describing it).
 upgrade.py/upgrade.sh assume min

 
 Now, granted, we can bootstrap from nothing as well.
 

7) You didn't ask. But I kinda think we should only have environment variables
that start CM3 -- CM3 and start CM3_ actually.
 

8) Another large meta point -- this is all clearly imperfect, usually
for lack of time or energy, not because we felt it was better this way.
Though there is the angle I gave -- portability.
Also, autoconf was probably less well established when most of this was written.
The build/conf world seems still to be somewhat unsettled.
 
 
9) I have a larger unimplemented vision -- the system should be redistributed as one portable hard to read C or C++ .tar.gz.
This doesn't work today, because "the frontend does layout" -- we essentially have 6 flavors of C:
 1 posix 32bit little endian (x86, etc.) 
 2 posix 32bit big endian (ppc_darwin, sparc32)
 3 posix 64bit little endian (amd64. etc.) 
 4 posix 64bit big endian (ppc64_darwin, sparc64)
 5 Windows 32bit little endian (x86 mips PowerPC alpha, arm32, etc. )
 6 Windows 32bit big endian (hypothetical xbox 360? CE?)    
 7 Windows 64bit little endian (amd64, ia64, alpha64 etc.) 
 8 Windows 64bit big endian (hypothetical xbox 360?) 
 
 
We could today make 6 distributions of just C and bootstrap from one of them, picking the right one.
 
Most 64bit systems can run 32bit, so strike those as bootstrap? But not quite, e.g. OpenBSD.
 
 
I'd like the option for the frontend to defer layout to the backend, and for the C backend to output string expressions involving sizeof(size_t) or sizeof(char*).
And, for win32 vs. posix, I'd like quake to compile both, and to generate a Makefile that picks the right one, or a .sh/.cmd.
 
 
Oh, and jmpbuf size is in the generated C. I know how to fix that.
bootstrap specifically could inflate it to the largest known case, which is quite large.
Or, once we generate C++ for excpetion handling, jmpbuf should go away.
 
 
 
 
   - Jay

 
> Date: Wed, 3 Jun 2015 08:17:49 +0200
> From: adacore at marino.st
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: [M3devel] It works! (was: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110)
> 
> On 6/2/2015 09:11, Jay K wrote:
> > John, this and your other problems should all be fixed now.
> > 
> > I was able to reproduce them mostly.
> > I didn't actually reproduce the cvsup problem, but I see in the log you
> > did set CM3, and I did test with that, and hit the cm3cg version
> > mismatch, and the problem is pretty clear -- my mistake.
> > 
> > I am able to start with I386_DARWIN 5.8.6 and either upgrade.py &&
> > make-dist.py or skip right to make-dist.py.
> > There was an additional problem skipping right to make-dist.py that I
> > fixed, at least for Darwin.
> 
> Hi Jay,
> I set up the VM last night and it completed the make-dist.py command.  I
> have some questions / comments.
> 
> comment 1:
> Using bin for config isn't a standard unix location.
> e.g. rather than <root>/bin/config/AMD64_FREEBSD, it should be located
> at <root>/etc/modula3/config/AMD64_FREEBSD  (can it be configurable?)
> 
> comment 2:
> Many of the binaries are might actually be example programs, e.g. cube,
> calculator, fisheye.  Rather than <root>/bin where they risk clashing
> with other programs, it might be advisable to stick them a
> <root>/share/examples/modula3  (configurable?).
> 
> comment 3: <root>/www is not standard either.  We would be this in
> <root>/share/doc/modula3.  Can it be configurable?
> 
> Comments 1--3 might be related because www might have relative paths
> that need changing
> 
> comment 4: I'd like a configurable option not to tar/gzip the products.
>  In my case, I'm going to stage them manually so this is an unnecessary
> step.
> 
> comment 5: the "min" distribution seems suitable to be packaged as a
> bootstrap
> 
> question 6: In most use cases, other than intentionally recreating the
> bootstrap, I'm not going to need the "min" distribution.  Is there any
> impact to building "all" only?  In other words, does something else use
> "min" distribution?
> 
> Thanks for the update!
> John
> 
> 
> 
> 
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150603/825c55fb/attachment-0002.html>