[M3devel] It works!

[John Marino]

On 6/3/2015 09:18, Jay K wrote:
> 1) "config"'s user configurability is over-implied imho.
> [snip]
> But also, we target not just Unix.
> Yet we have almost the same directory structure on Unix and Windows.
> The difference is that on Windows we put the .dlls in bin.

It is possible this was misunderstood.

It's important to release that cm3 will be installed nominally at
/usr/local/bin.  On a normal unix system, there could be over 500
packages all installing there.   Things like configuration files (.conf)
are nominally installed at /usr/local/etc/.  The config directory is
analogous to these.

I will do the following in any case:
 A) move config from bin to etc/<package>/
 B) edit cm3.cfg to point to new location

All I was suggesting is that the script do this for me.  It can still
install at bin/ by default, but it would be nice if it could install
elsewhere too.



>  Should we use $HOME/etc or $HOME/config?

Never.
This does not work for packaging.
E.g. prebuild binary packages that are installed (no building required)



> 2) "example" progs
> Yes. Remember how I said I was lazy and made just one, or rather two,
> package sets? That is what you are seeing here.
> Olaf did put more thought/work into this and the .sh files do build a
> few different distribution sets.

I am fine with what is built.  Remember above that cm3 is installed with
500 other packages.  Any program that is not essential and essentially
there as an example could (and my opinion) should be installed in a
place other than bin/.  I don't care if it's installed outside of PATH
because it probably won't be called much and absolute path is fine in
this case.

> 3) I think so. Look for "www" in config?
> 1-3) yes.
> In particular, are you aware of the
> rpath/origin/relink-upon-make-install/LD_LIBRARY_PATH situation?


I just remember that the current cm3 in ports, which is split up like I
suggest, had some broken links because I moved these things around.  I
can't remember what is actually broken; I'd have to check again.  The
point was you can't just move stuff around without changing links, so
the install script would have to do this if it supported alternative
locations.


> 4) 
> Just command line parsing in make-dist.py.

Right, but currently I have to patch make-dist.py to make it not
tar/gzip.  If the script supported the option, I could avoid that patch.


> 5) yes 
> 6) I don't understand.
> min is meant to be:
>  6a) a minimal toolset
>  You can write hello world.
>  cm3, cm3cg, mklib, config, m3core, libm3
>  text, threads
>  not a gui 
>  This is subjective. The "resource" stuff should probably be here.


The port is only going to install one distribution, and that will be the
"all".  The non-used one is just a waste of building; it will be thrown
away.

Ports framework repackages and stored in FreeBSD's binary package format.

> 7) You didn't ask. But I kinda think we should only have environment
> variables
> that start CM3 -- CM3 and start CM3_ actually.

that sounds logical but as long as they are defined it doesn't really
matter to me.


> 8) Another large meta point -- this is all clearly imperfect, usually
> for lack of time or energy, not because we felt it was better this way.
> Though there is the angle I gave -- portability.
> Also, autoconf was probably less well established when most of this was
> written.
> The build/conf world seems still to be somewhat unsettled.

if a python script is sufficient for port needs, this issue isn't
important to me.  So far it seems that it is.

> 9) I have a larger unimplemented vision -- the system should be
> redistributed as one portable hard to read C or C++ .tar.gz.
> This doesn't work today, because "the frontend does layout" -- we
> essentially have 6 flavors of C:
> We could today make 6 distributions of just C and bootstrap from one of
> them, picking the right one.
> Most 64bit systems can run 32bit, so strike those as bootstrap? But not
> quite, e.g. OpenBSD.

DragonFly is also 64-bit only.

> I'd like the option for the frontend to defer layout to the backend, and
> for the C backend to output string expressions involving sizeof(size_t)
> or sizeof(char*).
> And, for win32 vs. posix, I'd like quake to compile both, and to
> generate a Makefile that picks the right one, or a .sh/.cmd.
> Oh, and jmpbuf size is in the generated C. I know how to fix that.
> bootstrap specifically could inflate it to the largest known case, which
> is quite large.
> Or, once we generate C++ for excpetion handling, jmpbuf should go away.

no comment. :)

John