[M3devel] moving to new target names, in Hudson?

[Jay K]

I agree we agree, on the issues.
  I know I've been rambly though, so I'm not sure others understand.
  I had made these points earlier for Cygwin vs. native NT, but they were less valid there.
  The systems resembled each other less.


I'm nervous about my own suggestion though.
Don't worry about Windows here. It has excellent binary compatibility and the existing static configuration will work fine.
There is a similar matter with the C runtime version, which is also tied to the compiler version.
You see I already handled that in terms of archive names.


I also got "boot" archives working for I386_NT. The Makefile works with Microsoft nmake
and is very simple. The "boot" process produces .objs instead assembly source, which is
fine and good -- because of the integrated backend.


To be clear, on NT, I think having the user build the system is fine and good.
But instead of config.guess, probably just use "I386_NT_VC70", "I386_NT_VC80", "I386_NT_VC90", "I386_NT_VC100"
You can see in pylib.py I probe the compiler version trivially.
I guess I'll rewrite that in .cmd or JScript embedded in .cmd.
 That will do fine.


And like my proposal where we build a few Posix packages (maybe very few), we can build a few/very few .msis.


And just to remind everyone, m3src.tar.gz is split from m3cc.tar.gz, so that I386_NT users don't have to download
m3cc.tar.gz which they don't use.


Also to point out the obvious once you think about it:
 We can use DEC SRC for "guidance" but we cannot actually just go back to how it worked.
  In particular, because quake was written in C back then. They distributed C source to it.
  Small different really, as I believe they still distributed assembly of m3build.


Let's sit and think/talk about this longer before implementing something we decide we don't like.
I did start playing with autconf finally..been a long time coming.
Thing is..I don't think we need the full machinery of automake and even GNU make.
Depending on..another matter..

If you look at the existing boot archives, they just build cm3, Makefile is pretty simple.


autoconf will help, to find the C compiler, flags for -pthreads.
I put some annotations in m3core.h of stuff autoconf can figure out.


Question then: do we extend this and ship the entire system as assembly + C + makefiles?
That is, make user build m3cc, but then just assemble?


Or, only ship assembly for cm3?


I don't see a big difference either way.
Except that full system assembly + C dovetails nicely into things like iphone where you want to "finish"
the build not on the target, but using the "native cross" toolset.
ie: it is probably useful automation to have. Independent of if we distribute it.


But this does remind me...another thing autoconf can do...not autoconf actually, but libtool can be of use.
A bit of the config files is how to run the linker, shared vs. static. libtool is kind of gross and slow.
But this is what it does.
(Again, I just wouldn't do it for NT.)


"and another thing"
We can perhaps distribute patches to gcc instead of the full gcc tree.
State what version they are against, give a URL.
  We'd keep our tree for development convenience though.



"and another thing"
Back in the existing scheme of things..I was considering a go at upgrading m3gdb..


I'm still nervous.
Maybe we wait and see how much success/failure there is with the current release's binary distribution.
Mika's FreeBSD 4 problems and Mark's problem with 5.1 binaries on 4.0g aren't really enough to warrant doing much.
Except that we do understand the problem.


"and another thing"
To whatever extent systems are x86/amd64 and runnable in VMs, and to whatever extent they have good
backward compatibility, and to whatever extent Java is available on older systems. just building
on "oldest common denominator" might be good. (I just up the term. :) )


Probably this new stuff can be worked on and pondered..completely without upsetting the status quo.
I think so. Good.
I've had a big mental hurdle around autoconf/libtool for a long time but I'm finally starting to clear it..
I think they are part of the solution.


This will address the $ORIGIN stuff also of course, largely.
 (We still might provide a few binaries; maybe only for systems with $ORIGIN.)


 - Jay


----------------------------------------
> Date: Mon, 19 Jul 2010 16:28:35 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] moving to new target names, in Hudson?
>
> Hi Jay,
>
> I've learned several new things about Windows again; but in general,
> I don't think we disagree very much about the options and things to do.
>
> I agree that config.guess might be a good short-time option for the
> installation package names.
>
> I also agree that we could provide assembled packages for everything
> like PM3 did and rely on auto-configuration for everything else.
> This might be some more work for Windows though, as it uses a different
> backend than all other platforms. We'd need to create completely different
> Makefiles and scripts for Windows than for Unix and Unix-like systems.
> Or rely on some other tooling as prerequisite (either perl, python,
> Cygwin, ... you name it). I wouldn't like that very much though.
>
> I'm not sure yet if that would be welcome by all users and be seen
> as a step forward. I wouldn't mind it though.
> If it is generally accepted as a good idea, we should build up the
> infrastructure for that kind of packages and installations in parallel
> to what we have now.
>
> It would definitely not be the native Windows-installer user experience
> then ;-)
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>