[M3devel] It works!

[John Marino]

On 6/3/2015 11:30, Jay K wrote:
> I believe people typically install to /usr/local/cm3 instead of /usr/local.
> There is a philosophical problem here in terms of setup file system
> layout. /<packages>/package and then symlinks from /usr/local/{bin,lib}
> and removal of a package is just removing its one directory recursively
> and cleaning up any orphaned links vs. files put directly into
> /usr/local/{bin,lib} and data maintained on the side as to which file
> came from which package.

Well, setting it to /usr/local/cm3 would eliminate name clashes, but it
would also move cm3 out of the standard path.  That would require every
user to adjust their path.

If were were talking about 1-3 symlinks in /usr/local/bin then that
would be fine, but if it's like 25+ then that could be kind of pointless.

Plus on FreeBSD documentation, config, and examples go in standard
locations (if possible) and setting to /usr/local/cm3 without
modification wouldn't solve that.

We aren't worried about orphan files or whatever, the binary package
manager cleans up after itself when a package is removed, and won't let
two versions of a package be installed simultaneously, so there's no
real benefit to having cm3 in a dedicated directory (IMO).

> Just because it is called "config", does not make it "config".
> It should be refactored.
> And will there be some expectation that the "binaries" can be
> updated while leaving "config" alone?

No.  With updates, everything that was installed gets removed.  If this
is part of an update, everything is reinstalled.  There's always
integrity there.  For BSD setups, having it at etc/modula3/config makes
a lot of sense and there's no downside other than it's a different
location from releases that you guys may make.



>  > 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.
> 
>  
>  Send your patches here?
>  Or fork on github and send pull requests?

They wouldn't be suitable.  They would be patches to make the script
work meaning lines would be removed.  You're thinking about a patch to
handle both cases.

> Since you are going into ports, with an expected install place,
> and are building it yourself, you might want to mess with
> rpath, see here:

IIRC, the rpath was already fixed with the CM3 portable rpath option.  I
sort of recall hitting that before and finding $ORIGIN supported.

If RPATH is wrong it definitely needs fixing but I think it is a problem
that presents quickly (e.g. you couldn't use the product as a bootstrap).

John