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

Mon Jun 27 08:10:09 CEST 2016

On Sat, 25 Jun 2016 17:43:07 +0000
Jay K <jay.krell at cornell.edu> wrote:

> 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?

They invented docker-compose for that.

>   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 wouldn't like to give us dynamic linking, too, nor anything we have now.

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

See below.

> 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

Hi Jay and everybody else,

I think I've been slightly misunderstood; but that was to be expected.
I agree with most of the things you say. For now I'd just like to add
some more or less random comments:

* "backwards" didn't mean a step back for cm3, but only that I think that
  the approach it takes is just pragmatical: testing for everything that
  might be there or not. And it was certainly not intended to criticise
  anybody's recent work on cm3.
* I didn't really like cminstall, too, though I understand it might seem
  so. Replacing it with a more sophisticated configure/automake at
  installation time would probably help the installation very much.
* I doubt that generating C or C++ will be the right way to go, though
  I'm not against it as an alternative way/backend. The first versions
  of M3 used C as intermediate language, and after some years it was said
  to have been "a mediocre choice at best". Been there, done that.
* I think build systems need to provide a purely declarative interface
  for the user; m3makefiles/quake is a rather good implementation.
* I don't think we should try to make the M3 compiler behave more like
  a C compiler; rather than stepping from handling one package at a time
  to compiling single sources we need to look at building complete systems
  at a time.
* I don't think we should try to unify/combine the m3 package concept with
  OS installation packages.
* I don't think that using docker will help with providing a better
  build system, it might just help to make M3 more easily available to
  more users and thus help to keep the community alive.
* I don't think that the M3 community currently has the ressources to
  really solve the issues of a better build system and easy distribution
  with all existing OS platforms. There are just too few people and the
  tasks are too huge. So I thought it might be worth thinking of somehing
  completely different to attract more people.
* I guess that to come up with a reasonable declarative new or better
  build system, we'd need one common stable platform for it, and separate
  this task from those of achieving portability for all platforms.
  The platform might be an interpreter (like UCSD Pascal used or the JVM)
  or a really stable system and library interface (like an extended POSIX
  layer) or something completely new ;-) LLVM didn't seem to satisfy
  M3's needs, however, if I understood Rodney's laments correctly.
  Using an interpreter would also give up one of the big advantages of
  current CM3, that it can be compiled and linked natively on OSs.

Finally: There are too many sentences starting with "I". Please excuse me.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 
               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
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194