[M3devel] naming convention unix vs. grumpyunix?

[Jay K]

Slight clarification from earlier:

"Dependency on gcc" is

gcc or cc is a good way to run the correct assembler, which they decide to do for .s suffix, but not .ms/.is

And, it turns out, when faced with assembly source,
automake likes to run the C compiler.

If you imagine a strategy where we write automake intput, then .s helps.
Though the next possible step is automake being "native" -- and shiping some form of it for Windows, which I know doesn't go over well, but it really is impressive the extent that GNU build tools (gcc/ld) can target Windows -- it would be a good direction now for an AMD64 Windows port (besides the C backend...and ignoring LLVM...which maybe I should move my focus too...)

 - Jay

________________________________
> From: jay.krell at cornell.edu 
> To: hosking at purdue.edu 
> CC: m3devel at elegosoft.com 
> Subject: RE: [M3devel] naming convention unix vs. grumpyunix? 
> Date: Thu, 23 Jun 2016 00:38:18 +0000 
> 
> 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<mailto: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<mailto:M3devel at m3lists.elegosoft.com> 
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel