<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>"Yes".<BR> <BR><br>1)<br>"config"'s user configurability is over-implied imho.<br>It shouldn't all be considered config.<br>It needs refactoring into bin and config.<br>Possibly rewriting the stuff that has stood the test of a few year's time into<br>native Modula-3.<BR> <BR><br>It used to be worse.<br>Each file used to be standalone.<br>I refactored -- all the "common" files.<BR><br> <BR>I think it is partly called config because if you look at the<br>gcc source tree, it also has a config directory.<br><a href="https://github.com/modula3/cm3/tree/master/m3-sys/m3cc/gcc/gcc/config">https://github.com/modula3/cm3/tree/master/m3-sys/m3cc/gcc/gcc/config</a><BR> <BR><br>It should be called "target" perhaps.<BR>Heck, we could have bin/<target>/cm3cg, bin/<target>/cm3.cfg or bin</target>/config.quake or such.<BR> <BR><br>Consider all the Perl and Python and sh you may or may not have in /usr/bin.<br>Is it configurable? User editable? Maybe/kinda.<BR> <BR><br>Consider that /etc is often sh snippets.<BR> <BR><br>The line between code and data is somewhat blurry, and I am somewhat lazy.<BR><br> <BR>We could split the files into "less editable" and "more editable".<BR> <BR><br>The bulk of the text in the files is hard to understand and hard to edit.<BR> <BR><br>And then there is the question of updating. And when I make edits<br>to "the defaults", which do I assume are carried with cm3, vs. which<br>do I assume an update will leave alone?<BR><br> <BR>Basically, I'm lazy, and haven't perfectly evaluated or factored everything.<BR><br> <BR>It used to be worse.<br>However, there is/was cminstall, which the user is/was meant to run<br>which would edit small parts.<BR> <BR><br>So maybe those very parts should be broken out into separate files?<BR> <BR><br>There another problem though.<br>Which parts of "config"/cminstall need to be rerun when something else changes?<BR><br> <BR>You know, imagine I install cm3 and then I install X Windows.<br>Installing X Windows implies a need to reconfigure.<br>The full needs of a configuration system are related to a packaging system.<br>Debian I believe handles this all well, after years of development focusing<br>on these sorts of things.<BR><br> <BR>And then we'd have to handle all the other packaging systems.<BR> <BR><br>And nobody has been interested/motivated enough so far to really<br>integrate so well into all the various packaging systems.<BR> <BR><br>But also, we target not just Unix.<br>Yet we have almost the same directory structure on Unix and Windows.<br>The difference is that on Windows we put the .dlls in bin.<BR><br> <BR> Should we use $HOME/etc or $HOME/config?<br> And have /usr/local/cm3/bin probe around? I think I did put in some probing.<BR><br> <BR>To what extend do users just have private installs $HOME/cm3/bin<br>vs. sharing binaries and having just split off config?<BR> <BR><br>What if they want to change the compiled code?<BR> <BR><br>To what extent are systems multi-user?<BR> <BR><br>So "yes" there is work to do here and we need help :)<BR> <BR><br>2)<br>Yes. Remember how I said I was lazy and made just one, or rather two,<br>package sets? That is what you are seeing here.<BR> <BR>Olaf did put more thought/work into this and the .sh files do build a few different distribution sets.<BR> <BR><br>3) I think so. Look for "www" in config?<BR> <BR> <BR>1-3) yes.<br>In particular, are you aware of the rpath/origin/relink-upon-make-install/LD_LIBRARY_PATH situation?<BR><br> <BR>I went with origin.<br>I didn't have the energy or perhaps the buy-in to implement relink-upon-install approach.<BR><br> <BR>Previously we relied on either paths being correct *before* make install, or setting LD_LIBRARY_PATH.<br>Both are bad solutions.<br>There are I believe approx. 4 choices, for redistributable binaries that might go to a variety of setups:<BR> <BR><br> a) paths correct on original build machine <br> b) LD_LIBARY_PATH <br> c) origin <br> d) relink upon install (leaving binaries not further relocatable by mv/cp). <BR>I went with c.<br>So if you move samples around, you have to deal with that.<br>bin/samples would seem easy enough though.<BR> <BR><br>Or heck, a peer of bin? lib? samplebin? samples?<BR> <BR><br>I think if we adopted automake/libtool, we'd get #c and it would be kinda good.<br>Do cmake users use libtool?<BR> <BR><br>You know meta meta meta point -- we have our own little close to state of the art<br>build system, but not quite state of the art. It works prety well and pretty portably.<br>But not always as well as people would like.<BR> <BR><br>Between autoconf and Perl's method of port to every system, we are more like Perl,<br>but also trying to find least common denominators that don't actually have to be ported.<BR> <BR><br>Does this make some sense?<BR> <BR> <BR>4)<BR><br>Just command line parsing in make-dist.py.<BR> <BR><br>5) yes<BR> <BR> <BR>6) I don't understand.<br>min is meant to be:<br> 6a) a minimal toolset<br> You can write hello world.<br> cm3, cm3cg, mklib, config, m3core, libm3 <br> text, threads<br> not a gui <br> This is subjective. The "resource" stuff should probably be here.<BR> <BR><br> 6b) It is meant to be enough to bootstrap another cm3 version from,<br> older or newer. cm3 manages its dependencies carefully.<br> It either carries things itself, or they are in min.<br> For example, it doesn't use X Windows (or .i3 files describing it).<BR> upgrade.py/upgrade.sh assume min<BR><br> <BR> Now, granted, we can bootstrap from nothing as well.<BR> <BR><br>7) You didn't ask. But I kinda think we should only have environment variables<br>that start CM3 -- CM3 and start CM3_ actually.<BR> <BR><br>8) Another large meta point -- this is all clearly imperfect, usually<br>for lack of time or energy, not because we felt it was better this way.<br>Though there is the angle I gave -- portability.<br>Also, autoconf was probably less well established when most of this was written.<br>The build/conf world seems still to be somewhat unsettled.<BR> <BR> <BR>9) I have a larger unimplemented vision -- the system should be redistributed as one portable hard to read C or C++ .tar.gz.<BR>This doesn't work today, because "the frontend does layout" -- we essentially have 6 flavors of C:<BR> 1 posix 32bit little endian (x86, etc.) <BR> 2 posix 32bit big endian (ppc_darwin, sparc32)<BR> 3 posix 64bit little endian (amd64. etc.) <BR> 4 posix 64bit big endian (ppc64_darwin, sparc64)<BR> 5 Windows 32bit little endian (x86 mips PowerPC alpha, arm32, etc. )<BR> 6 Windows 32bit big endian (hypothetical xbox 360? CE?) <BR> 7 Windows 64bit little endian (amd64, ia64, alpha64 etc.) <BR> 8 Windows 64bit big endian (hypothetical xbox 360?) <BR> <BR> <BR>We could today make 6 distributions of just C and bootstrap from one of them, picking the right one.<BR> <BR>Most 64bit systems can run 32bit, so strike those as bootstrap? But not quite, e.g. OpenBSD.<BR> <BR> <BR>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*).<BR>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.<BR> <BR> <BR>Oh, and jmpbuf size is in the generated C. I know how to fix that.<BR>bootstrap specifically could inflate it to the largest known case, which is quite large.<BR>Or, once we generate C++ for excpetion handling, jmpbuf should go away.<BR> <BR> <BR> <BR> <BR> - Jay<br><br> <BR><div>> Date: Wed, 3 Jun 2015 08:17:49 +0200<br>> From: adacore@marino.st<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: [M3devel] It works! (was: m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110)<br>> <br>> On 6/2/2015 09:11, Jay K wrote:<br>> > John, this and your other problems should all be fixed now.<br>> > <br>> > I was able to reproduce them mostly.<br>> > I didn't actually reproduce the cvsup problem, but I see in the log you<br>> > did set CM3, and I did test with that, and hit the cm3cg version<br>> > mismatch, and the problem is pretty clear -- my mistake.<br>> > <br>> > I am able to start with I386_DARWIN 5.8.6 and either upgrade.py &&<br>> > make-dist.py or skip right to make-dist.py.<br>> > There was an additional problem skipping right to make-dist.py that I<br>> > fixed, at least for Darwin.<br>> <br>> Hi Jay,<br>> I set up the VM last night and it completed the make-dist.py command. I<br>> have some questions / comments.<br>> <br>> comment 1:<br>> Using bin for config isn't a standard unix location.<br>> e.g. rather than <root>/bin/config/AMD64_FREEBSD, it should be located<br>> at <root>/etc/modula3/config/AMD64_FREEBSD (can it be configurable?)<br>> <br>> comment 2:<br>> Many of the binaries are might actually be example programs, e.g. cube,<br>> calculator, fisheye. Rather than <root>/bin where they risk clashing<br>> with other programs, it might be advisable to stick them a<br>> <root>/share/examples/modula3 (configurable?).<br>> <br>> comment 3: <root>/www is not standard either. We would be this in<br>> <root>/share/doc/modula3. Can it be configurable?<br>> <br>> Comments 1--3 might be related because www might have relative paths<br>> that need changing<br>> <br>> comment 4: I'd like a configurable option not to tar/gzip the products.<br>> In my case, I'm going to stage them manually so this is an unnecessary<br>> step.<br>> <br>> comment 5: the "min" distribution seems suitable to be packaged as a<br>> bootstrap<br>> <br>> question 6: In most use cases, other than intentionally recreating the<br>> bootstrap, I'm not going to need the "min" distribution. Is there any<br>> impact to building "all" only? In other words, does something else use<br>> "min" distribution?<br>> <br>> Thanks for the update!<br>> John<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br></div> </div></body>
</html>