[M3devel] naming convention unix vs. grumpyunix?

Thu Jun 23 08:33:00 CEST 2016

Did you ever consider 0install as a means of distribution?

From: Jay K 
Sent: Thursday, June 23, 2016 2:38 AM
To: Hosking, Antony L 
Cc: m3devel 
Subject: Re: [M3devel] naming convention unix vs. grumpyunix?

This is a bit long and out of order, sorry. 
Simple story is for us to get out of the platform-specific build system maintenance business, and reuse larger portability from other projects.

I've been wrestling with this in my head a long while. 

- I don't like maintaining the config files. 
   It is hard to be an expert on dynamic linking across "many" operating 
   systems, linkers, versions. 

- I don't like that for example an AIX port remains absent.
   And now I see AIX doesn't have $ORIGIN.

- It bothers me just slightly that we aren't portable
   to the older systems that lack $ORIGIN.

   $ORIGIN is nice if you are redistributing binaries, 
   that will be moved around, but it was never needed 
   for self-built software, or software installed to 
   an agreed upon place, and it isn't supported in setuid or such
   programs. 

  (Aside -- and remember how bad it used to be?
   We used to distribute binaries with random hardcoded paths,  
   and advise people to set LD_LIBRARY_PATH. Even for stuff people
   self-built, it wasn't good. So I did improve things 
   but I don't think it is worth us doing ourselves.) 

- Our current bootstrap/cross-build story isn't automated enough. 
   And then, what should it look like? 

- Generating cmake or autoconf/automake/libtool input provides some potential answers. 

   I'd really like to delegate to folks that did and will continue to port pretty much everywhere.  
   Sometimes I think, hey, we can just do what we need ourselves, but then I see how 
   much gnarly system-specific knowledge autotools/cmake deliver nicely to their users. 

   I had a mental stumbling block for years with cmake/autotools but finally 
   got over it. I have prototyped some simple uses, both with recursive 
   make and non-recursive make. 

   configure is a bit slow, but we'd have a very minimal one.
   The resulting make invocations are ok. 

   I can almost just generate makefiles myself, but then for example
   I don't know much about "install". cmake/automake provide me "install"
   with me knowing nothing. 

   I don't really want to be an expert in make, compiler flags, linker flags,
   Posix portability gotchas, etc. -- ok maybe at the libc/m3core level, but
   not so much as the make/sed/awk/sh level. 

  There are a few details of autoconf/cmake/libtool I don't like, where the Modula-3
  build system is clearly and simply superior. And other areas where I'm not
  sure what is ideal.

  Where Modula-3 is clearly superior in that in producing static and dynamic
  libraries, it only ever compiles once. cmake and libtool are pretty keen
  on compiling everything twice -- even with identical command lines.

  Where I'm not sure is our probing for libraries and the build_standalone feature.
  I think if we did things a little different/better, we wouldn't even have cm3
  be standalone.

  I very much want to offer to users the:
    tar xf cm3...
    cd cm3... 
    configure 
    make 
    make install 

sort of experience. 

There are slight difficulties. 
configure probes the C compiler for what it produces.
Let's ignore C-backend and LLVM for now and consider cm3cg.

The likely best bootstrap format is assembly source. Like the 3.6 release. 
For just cm3/m3core/libm3, or the entire system? 

So configure probing vs. having on hand possibly just one assembly source is a bit of a misfit.  

Perhaps configure would be tailored to hardcode what the distribution contains. 

Or perhaps the distribution would contain "everything" and configure would pick the right one. 
It is obviously wasteful, but these days maybe ok, and the result easier for people to install.

The C generating backend doesn't fix this much or entirely, since the C is still target-specific.
Maybe we can fold the C down to just a few platforms, and then the idea of one cross-platform distribution
might work. Maybe eventually the generated C can speak in "integer" and array/struct references, instead
of front-end computed offsets, but that is a ways off. 

autotools/libtool also solve that problem where non-shipped binaries don't run. 
Something we have hacked on by sprinkling build_standalone around. 
I'm not sure if cmake fixes this. 

I'm not sure they solve it the way I want though -- I'd like to have the uninstalled
paths hardcoded, then relink or otherwise binary edit in install. 

One thing I need to study a bit more is how to install all the extra stuff to the pkg directories.

As well,...so many things... we have this structure: 
   bin/foo
   lib/foo.so (did I do this? No matter, the layout is wierd w/o it.)
   pkg/foo/TARGET/foo.so 

I have always found it a little suspicious that binaries have implicit TARGET
but pkgs have explicit TARGET. I somewhat pine for a layout that can accomodiate
all targets including the bin directory.

I suppose if bin and lib are what run, and pkg is only for building, this accomodates
unshipped cross builds nicely. But ideally you could have a runnable PPC_DARWIN/I386_DARWIN/AMD664_DARWIN
system all in structure (caveat that PPC_DARWIN doesn't work in Rosetta because of our
preemptive suspend -- cooperative suspend would fix that.) 

- Jay

--------------------------------------------------------------------------------
From: hosking at purdue.edu
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] naming convention unix vs. grumpyunix?
Date: Wed, 22 Jun 2016 21:19:12 +0000

Why import dependencies on make and automake?

Sent from my iPad

On Jun 22, 2016, at 9:41 PM, Jay K <jay.krell at cornell.edu> wrote:

  I propose making unix match grumpyunix and removing grumpyunix. 

  There is slight upside and should be no downside.

  The upside is that various tools -- make and automake -- know that .s is assembly and will assemble it.

  Is it a downside for base name to change foo.m3 => foo_m.s/foo_m.o vs. foo.m3 => foo.ms/foo.mo?

  I expect everything will just work.

  - Jay

  _______________________________________________
  M3devel mailing list
  M3devel at m3lists.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/20160623/5bb7b260/attachment-0002.html>