[M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
Jay K
jay.krell at cornell.edu
Mon Jun 1 21:47:48 CEST 2015
Sorry I'm rushing here..:
Imho, build should build and ship should ship and buildship should do both.
If that isn't the case, we should fix.
Then, if you don't want to ship something, don't ship it.
Not, ship it and set the environment variable.
>implied: What is override?
There are essentially two package pools, or sets of libraries, to chose from.
They are roughly speaking the installed/shipped stuff:
/usr/local/cm3/pkg/m3core/target (obviously it can vary)
and the locally built but not yet shipped stuff, I call them:
$HOME/dev2/cm3/m3-libs/m3core/target (obviously it can vary)
I also call this "the object tree", i.e. the tree with a bunch of .obj/.o files.
Or the "intermediates" tree, i.e. a bunch of outputs that are pruned out by "setup",
and the outputs that are ultimately interesting
The default is the first, override means to use the second.
Then, the idea is that only stuff built against the install is safe
to overwrite/add to the install.
But I think is missing there is that, well, if I've built the entire
system with overrides and I'm going to ship the entire system, then ship is safe.
This isn't the best approach imho.
Arguably better approaches are:
always have a 2-level search
first the object tree
then the install tree
This breaks people who switch around between
incompatible changes in m3core and random application development,
with the same source/object tree. However maybe that is just tough.
The object tree doesn't have to be in the source tree.
You should be able to say, like:
symlinktree /usr/local/cm3 /working-on-feature1
export/set CM3_SOMETHING=/working-on-feature1 and
case I change cm3 also export/set PATH=/working-on-feature1/bin:$PATH
and then copy on write as you ship
and then to switch to some other work:
symlinktree /usr/local/cm3 /working-on-feature2
export/set CM3_SOMETHING=/working-on-feature2 and
case I change cm3 also export/set PATH=/working-on-feature2/bin:$PATH
and then copy on write as you ship, different stuff
That is a working model that I advocate but don't yet follow. Though make-dist kind of does.
make-dist copies the compiler to the new location and then does buildship.
In this model, you don't have overrides and you always build/ship.
And if you mess up, you can start over easily.
But I haven't actually established workflow here so I'm just talking too much. :
A real analog in other people's workflows is:
mkdir /obj/working-on-feature1
cd /obj/working-on-feature1
/src/configure ...
make
mkdir /obj/working-on-feature2
cd /obj/working-on-feature2
/src/configure ...potentially different ..
make
.sh build should not ship. Agreed.
Currently if you are going to ship, you can't override.
make-dist.py uses a destdir-like approach.
There is some contention perhaps of scenarios of "I'm just building a little,
small safe changes" and "I'm rebuilding everything, and possibly messing up".
I really want the environment variable checks to go away.
- Jay
> Date: Mon, 1 Jun 2015 12:48:34 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
>
>
>
> On 06/01/2015 01:40 AM, Jay K wrote:
> > Yes, exactly, that's what I was trying to say, in my later/last mail.
> >
> >
> > Yes the compability is definitely two-way.
> > There is a one to one mapping back and forth.
> > cm3 goes with cm3cg; cm3cg goes with cm3.
> > Neither is compatible with older nor necessarily newer versions.
> >
> >
> > They would be statically linked together if not for the GPL.
> >
> >
> > When I first placed m3cc in pkginfo.txt years ago, I was only thinking
> > of build order and, like, "override".
> >
> >
> > m3cc imports nothing and nothing imports m3cc.
> > In the Modula-3 module/library/interface sense.
> >
> >
> > It can be built when you have nothing.
> > So I figured put it nearly first.
> >
> >
> > Only now today did I consider the shipping order.
> > It should be shipped adjacent to cm3, either right before or right after.
> >
> >
> > If you split build and ship, then it can still be built early,
> > or at almost any time.
> >
>
> Yes, this is the way I want to do building. First build everything you want to
> without putting any of it into use as build tools. Then put it all into use.
>
> One annoyance we currently have is that the do-cm3.*.sh scripts have, perhaps
> we should call them subcommands, like realclean, build, ship, buildship, etc.
> But the cm3 command treats their counterparts as command line options,
> -realclean, -build, -ship, -buildship, etc. I would like to consistify
> this. Removing the hyphen from cm3 would create ambiguities with file names,
> so it would mean adding the hyphen to the scripts.
>
> Much more serious is that similarly-named options do not have the same meaning
> in the scripts and in cm3. cm3 -build followed by cm3 -ship works as I expect,
> but do-cm3-*.sh build causes me nothing but trouble, and I learned long ago to
> avoid it. Instead, I always use do-cm3-*.sh buildship. This ships almost everything
> as it is built, but usually only cm3 and cm3cg executables matter, and today, they are
> specifically excepted from shipping, if you do not set INSTALL_CM3_IN_BIN="yes".
>
> I am writing from memory, but I think the problem with do-cm3-*.sh build is that
> build also uses overrides, which I barely understand, except that they, at best
> make things unshippable, and I think there was some other problem too. If we
> made the override thing a separate option to the scripts, so just build would
> neither ship nor override, I think that would satisfy my need, at least for the
> time being. And it would be consistent.
>
> Actually, I think we do want to use just-rebuilt packages when linking to them.
> Only executables and things they link in (possibly dynamically) need to be
> left alone until a later ship step. This usually only means cm3, cm3cg,
> and, if dynamically linked in, m3core. But there are others to think about,
> e.g., m3bundle, stubgen, netobjgen.
>
> >
> > But we have one ordering for build and ship, so let the shipping order decide.
> >
> >
> > I still don't like INSTALL_CM3_IN_BIN and I'd still like to remove it.
>
> I have no objection to addressing the copy-over-an-executing-executable problem
> in a different way, and no objection to getting rid of the environment variable.
> But I do want it, for now at least, to be possible to get it to not ship either
> cm3 or cm3cg, even with the buildship option. If it just unconditionally doesn't
> ship them, that is fine. Before I added the variable check for the cm3cg package,
> it was unconditionally shipping it.
>
> > I still think it broke upgrade.py.
> > I can workaround. But I'd like to remove the environment variable check.
> >
> >
> > There are many order dependencies in build and ship. This is just one.
> >
> >
> > - Jay
> >
> >
> >
> >
> > > Date: Sun, 31 May 2015 22:28:13 -0500
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com; adacore at marino.st
> > > Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp (0x100), expected 0x110
> > >
> > > I am quite sure that the cm3/cm3cg incompatibility is two-way, i.e.,
> > > both must be new or both old. So, I would expect INSTALL_CM3_IN_BIN=yes
> > > to fail regardless of the order of building the two.
> > >
> > > OTOH, if cm3 were built and shipped, then m3cc came immediately after,
> > > it should work, because m3cc contains no Modula-3 code, and the new
> > > cm3 would not, when building it, run cm3cg. After that, there would
> > > be a consistent set. for further compiles. But any package containing
> > > M3 code built between cm3 and m3cc would fail.
> > >
> > > On 05/31/2015 05:15 PM, Jay wrote:
> > > > I think now it might not be the problem. Could be m3cc needs to be later in pkginfo.txt. I have to try later.
> > > >
> > > > - Jay
> > > >
> > > > On May 31, 2015, at 10:59 AM, John Marino <adacore at marino.st> wrote:
> > > >
> > > >> I removed "INSTALL_CM3_IN_BIN=yes" after reading the thread about it.
> > > >> Should I put it back? From the last response I'm guessing that wasn't
> > > >> the problem.
> > > >>
> > > >> John
> > > >>
> > > >>
> > > >> On 5/31/2015 19:09, Jay K wrote:
> > > >>> Oh probably the problem is using the backend premature actually.
> > > >>> Darn, I can't help right now.
> > > >>>
> > > >>> - Jay
> > > >>>
> > > >>>
> > > >>>
> > > >>> ------------------------------------------------------------------------
> > > >>> From: jay.krell at cornell.edu
> > > >>> To: adacore at marino.st; m3devel at elegosoft.com
> > > >>> Date: Sun, 31 May 2015 16:45:42 +0000
> > > >>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
> > > >>> (0x100), expected 0x110
> > > >>>
> > > >>> Hm. Strange. I need to read more closely. I see it skipping shipping,
> > > >>> but my read was it didn't try that.
> > > >>> So.. with INSTALL_CM3_IN_BIN=yes?
> > > >>> I need to try this all, and "fix" it to set that. The whole thing in
> > > >>> m3cc/src/m3makefile is relatively
> > > >>> new vs. when I was actively using all this. :(
> > > >>>
> > > >>> - Jay
> > > >>>
> > > >>>
> > > >>>> Date: Sun, 31 May 2015 16:57:02 +0200
> > > >>>> From: adacore at marino.st
> > > >>>> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> > > >>>> Subject: Re: [M3devel] m3cgc1: fatal error: *** bad M3CG version stamp
> > > >>> (0x100), expected 0x110
> > > >>>>
> > > >>>> On 5/31/2015 11:53, Jay K wrote:
> > > >>>>> John, have you tried make-dist.py?
> > > >>>>> i.e.
> > > >>> https://github.com/modula3/cm3/blob/master/scripts/python/make-dist.py
> > > >>>>>
> > > >>>>> While it might not be exactly what you need, it should demonstrate the
> > > >>>>> elements.
> > > >>>>>
> > > >>>>> I will try to try this all soon, really, I hope so.
> > > >>>>>
> > > >>>>> It starts with a working compiler, does no in-place updates, build into
> > > >>>>> a unique directory in /tmp, and gives you .tar.gz or such at the end.
> > > >>>>> It does "min" and "all".
> > > >>>>>
> > > >>>>> If you set the STAGE environment variable, it uses that instead of /tmp.
> > > >>>>> It should probably be called M3_STATE or M3_MAKEDIST_STAGE.
> > > >>>>>
> > > >>>>> - Jay
> > > >>>>
> > > >>>> Hi Jay,
> > > >>>> I'm getting the same error as always using make-dist script:
> > > >>>> http://leaf.dragonflybsd.org/~marino/m3d.log
> > > >>>>
> > > >>>> Thanks,
> > > >>>> John
> > > >
> > >
> > > --
> > > Rodney Bates
> > > rodney.m.bates at acm.org
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150601/32137a95/attachment-0002.html>
More information about the M3devel
mailing list