[M3devel] M3 Portabilbity, Installation, Distribution -- use Docker Containers for Easy Access?

Sat Jun 25 20:17:11 CEST 2016

Hi Jay, all:do you  remember that pm3 build run in make; do you remember the cross platform assembly generation model.What do you think of it?
Thanks in advance 

    El Sábado 25 de junio de 2016 12:43, Jay K <jay.krell at cornell.edu> escribió:

 #yiv0826315534 #yiv0826315534 --.yiv0826315534hmmessage P{margin:0px;padding:0px;}#yiv0826315534 body.yiv0826315534hmmessage{font-size:12pt;font-family:Calibri;}#yiv0826315534 I agree and disagree.

Regarding Posix -- I think it did well for low level C.

I think we have some portability in Modula-3 as a result.I agree they seemed to have done nothing for shared linking, for packaging,and almost nothing for "make", and I guess X Windows didn't need their help,at the time, people thought.

There is a clear resemblance among the build systems.Even automake looks like cm3 from a user point of view.Even the implementation: automake "compiles" to make cm3 "compiles" to quake
 Quake was written in C.

The notion of a bunch of builtins and some escape hatch is also common.Quake is a better escape hatch than cmake.

The notion of writing a build scripting language and/or a set of build functionsaccessible to a scripting language is common -- in scons it is all just Python,and they provide a library. The Unity?Unreal (I get these mixed up) build systemhas all the "makefiles" written in C#, and actually adding a single source fileimplies some automatic recompile, but it is a small/fast recompile, andthe resulting build system is fast, AND you can step through your build systemusing an ordinary C# debugger -- trying doing that with cm3/quake/make!

cm3 kind of delegates to something kind of like autoconf, if you consider cminstall.But the cminstall part I never liked -- it was interactive and we still haveto maintain the choices, and it was often wrong. It was too close to the "user edits it" model.

I'm aware of Docker.

I think it is solving a problem.  Not the entire problem -- cloud app declaration, software composition.  Though it still low level -- how do I describe and join multiple containers?
  I'm not sure it is relevant here.

However, Docker-induced bloat alludes to static link bloat.If we give up on dynamic linking, we get Posix-portable linking --ar + ranlib + cc/ld are very portable. I'm reluctant to do that though.

I don't think C and autoconf/automake are clearly a step backward.

I want more portability and, I admit, less work. I think they are great for portabilitity. Even better, generate C++ and likely gain efficient exception handling. Delegating the work to the C++ implementers, which generally do much better than us here (basically inheriting "stack walkers" wherever they exist.)

I want to be able to declare large swaths of the system ported/portableand not have to constantly revisit them (or worry that they are neglected)

I don't want clang vs. gccto be something we have to worry about. I want want minor forkslike Dragonfly or the new OpenBSD fork to be something that requiresour attention to work, or perhaps even anyones -- if these systems resemblePosix enough and/or use gcc, autoconf can just figure stuff out. Or maybewe just have to pick up newer libtool sometimes.

If I write a substantial program in C or C++, and I use cmake or autoconf/libtool,I can redistribute it easily as source and people can easily rebuild and installand package it. I want our system to be similar.

There are middle grounds that don't "step backward".We could: - accept our current platforms/ports (i.e. don't fret over AIX, etc.)  - accept that the config files aren't bad asis  - bootstrap can just automate slightly more and build cm3  - use cm3 to build and install everything else, including cm3cg,   dynamic linking, etc.    That is, we can get close to configure && make && make install w/o muchchange. Mostly like 3.6.

One nagging point is to distribute target specific cm3 bootstraps, or bundlethem all together and have something like "configure" pick which one.You know -- does user have to pick among many downloads or just one.
We can maintain the "configure && make && make install" model, butthey wouldn't use any of autoconf/automake.
configure would determine what target to usemake would cd to that target and build cm3, statically linkedmake would then use that cm3 to the entire system -- starting with cm3cg, and then m3core The system it is building would have to be matched with the cm3 itself. It might turn around at the cm3 point and use that cm3 to rebuild.

This is only a minor layering/scripting over what we already have.
This configure might be written in portable sh or portable C/C++, but it doesn't have to do much.The make step, boot1.py already generates makefiles, but that could be pushed into shor C/C++ if desired.
Honestly, there is a problem that I just find sh very difficult to adopt for anything.Python or C or C++ are much preferable to me.This construction does delegate mostly to Modula-3, but for some bootstrapping.
Still though, I still wonder about replacing the config files with libtool...Generating Makefile.am from the m3makefiles..and btw, we'd run "make -j" -- parallelism!
 - Jay

> To: wagner at elegosoft.com; m3devel at elegosoft.com
> From: adacore at marino.st
> Date: Sat, 25 Jun 2016 16:06:12 +0200
> Subject: Re: [M3devel] M3 Portabilbity, Installation, Distribution -- use Docker Containers for Easy Access?
> 
> On 6/25/2016 2:24 PM, Olaf Wagner wrote:
> > Lurking in the shadows and reading all the recent mails about improving
> > the build system and seeing more and more steps 'backwards' to adapt
> > to C, autoconf, makefiles and more overcome tools and concepts, a
> > heretical thought comes to mind: Have you ever considered using docker
> > as a means to provide easy access and distribution of Modula-3?
> 
> You mean Linux-only Docker?
> 
> In general this concept would not be compatible with typical s/w build 
> repositories used by various OS. If you went to a primary Docker 
> distribution system, you're basically saying A) M3 is limited to Linux 
> and B) It's distributed by third parties (you) only.
> 
> At first glance, I'd say it's a bad idea.
> 
> John
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://m3lists.elegosoft.com/mailman/listinfo/m3devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160625/72f0075b/attachment-0003.html>