[M3devel] proposal for next release: moving some config file content into cm3

[Jay K]

> If these cannot be overriden by the config files, system specific
> installations not adhering to the standard layout won't be possible.


They shall be overridable, but perhaps only INSTALL_ROOT?
It becomes ambiguous, as to when to resolve INSTALL_ROOT in code like


PKG_INSTALL = INSTALL_ROOT & /pkg

PKG_USE = INSTALL_ROOT & /pkg

or
PKG_USE = PKG_INSTALL




You have to decide what order things are processed -- builtin defines then command line, or command line then builtin defines, or loop while things change.


Could I on the command line say -DPKG_USE="INSTALL_ROOT & '/foo'" ?
Does cm3 -DINSTALL_ROOT=/foo imply PKG_USE=/foo/pkg?

An easy answer is to only allow overriding USE_ROOT and INSTALL_ROOT.
That all the rest follow directly by appending /bin, /pkg, /lib.
I guess as well each one is "fully" overridable, but overriding "part of an expression" won't cause that expression to be reevaluated, and all the builtins are evaluated..first? last? Can I say PKG_USE=INSTALL_ROOT & /foo? Is INSTALL_ROOT defined before or after the command line is processed? I don't mean currently, but ideally.

> > That is something to consider.
> > cm3 should perhaps even move to an archictecture-specific directory.
> >    /cm3/bin/I386_LINUX/cm3
> >
> > However, aside, I've given up on that idea.
> 
> Why? Too complex? Is there some strong argument against it?
> (I don't remember offhand.)


If I'm going to have /cm3/bin/target, /cm3/lib/target, /cm3/pkg/m3core/target, and it is going to take work to teach things about this, it seems easier and almost equivalent to use /cm3.target/bin, /cm3.target/lib, or /cm3/target/bin, /cm3/target/lib, etc.
The downside is some duplication, of the src directories in pkg, the config files (we can fix that, but very minor), doc, man..all fairly small..on Windows at least there is something called the "single instance store" that opportunistically finds identical files and combines their storage but makes them copy-on-write.


I know I know -- "make whatever is different, different; leave whatever is the same, the same".
But sometimes it is easier to just pretend everything is different, when it is almost true anyway.

I wonder how cross builds fit here however.
That might be a reason to have
  /cm3/bin/cm3
  /cm3/lib/target
  /cm3/pkg/m3core/target (already the case) 


in that, you know, even though "biarch" and "multiarch" are "limited" to a maximum of around 3 (ppc, x86, amd64 darwin; cygwin, interix, native NT), cross combinations occupy the whole matrix, but only lib would get duplicated, not bin.


The thing is, I find "full" cross builds to be too much of a pain -- the actual C compilation, assembly, link, so I don't account for them. You need to build or copy the C runtime and headers, build the cross compiler and assembler.
The problem imho is that 1) it isn't even always possible, consider the case when the native tools are preferred over GNU and aren't open source (Irix, AIX, HP-UX?) 2) when it is possible, it varies, as the C runtime/headers have to be gotten a different way for each system (*BSD, Solaris, Linux, Windows). It is only "the same everywhere" if you define "everywhere" as one system such as FreeBSD OR Linux OR NetBSD.
I have done this, copied /usr, /lib etc. from Solaris to a cross build host..but..as well..you don't even know which files. Perhaps I should use NFS and therefore get all the files more cheaply..


Hm.
so /cm3/lib/target.
And we use that for native too?
Using symlinks for compat?


And /cm3/bin/target.
And /cm3/bin/cm3 is a .sh file with an except of sysinfo.sh?
(and cm3.cmd would exist)


And adjust the computation of INSTALL_ROOT?
And the location of cm3.cfg?


For the sake of "full" cross builds (ie: C compilation, assemble, link)?

In either case, these are separate.
Except that they relate regarding the computation of INSTALL_ROOT.
The code for INSTALL_ROOT computation could be smart.
If cm3's directory ends in "bin/host", remove two elements.
If it ends in "bin", remove one element.
If it ends in "m3-sys/host" error probably, or maybe search $PATH for another cm3 and apply the logic to its location.
If anything else, error.


 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090810/4ed9d3cf/attachment-0002.html>