1. Standardizing file locations
One of the goals of getting euphoria installed via a package manager, is
that we could also install our own libraries in a similar way. In
particular, this would be convenient for wxEuphoria, since it needs to
install a shared library. Having looked at the way perl handles these
sorts of issues, here's what I'm thinking now:
Standard includes (i.e., the normal $EUDIR/include dir) go right in
/usr/share/euphoria
3rd party installed includes could go into their own subdir of
/usr/share/euphoria
That way, we wouldn't have to add anything to a .conf file, and we could
simply say (as a standard way of using these things):
include somelib/lib.e
This could be the 'standard' way of doing things for other platforms as well.
It would work whether the library were installed 'properly' on the system,
or if it were simply put in as a subdir from the main app, which would
make distribution easier and cleaner.
Likewise, documentation could go into /usr/share/doc/euphoria/somelib
But where to put demos? I think the best place is probably to stick them
in either
/usr/share/euphoria/demo/somelib
or
/usr/share/euphoria/somelib/demo
Given this, here is my current thoughts on how to package wxEuphoria:
There will be two packages: wxeu and wxeu-dev
This is based on reading the Debian policy manual regarding shared
libraries. Basically, the wxeu package would only contain the shared
library itself. The dev package would have the euphoria include file,
as well as the documentation and the demos.
So I'd put the files:
package: wxeu
/usr/lib/libwxeu.so (actually, I'm looking to adopt the standard versioning
methodology, so it would probably be something like
libwxeu.so.12)
package: wxeu-dev
/usr/lib/libwxeu.so (symbolic link to the versioned library)
/usr/share/euphoria/wx/wxeud.e
/usr/share/euphoria/demo/wx/* (all the demos)
/usr/share/doc/euphoria/wx/*html (all the docs)
I'd also distribute the standard source .tar.gz package so that people
could easily build from source.
Matt
2. Re: Standardizing file locations
- Posted by Robert Craig <rds at RapidEuphoria.c??>
Jan 12, 2008
-
Last edited Jan 13, 2008
Matt Lewis wrote:
> One of the goals of getting euphoria installed via a package manager, is
> that we could also install our own libraries in a similar way. In
> particular, this would be convenient for wxEuphoria, since it needs to
> install a shared library. Having looked at the way perl handles these
> sorts of issues, here's what I'm thinking now:
>
> Standard includes (i.e., the normal $EUDIR/include dir) go right in
> /usr/share/euphoria
>
> 3rd party installed includes could go into their own subdir of
> /usr/share/euphoria
That sounds good.
Keep in mind though that some people will want
to use Euphoria on a shared host machine
where they might not have permission to put stuff
into /usr/share
For instance, on both OpenEuphoria.org (Linux)
and RapidEuphoria.com (FreeBSD) the
/usr/share directory exists, but I don't have permission
to create a subdirectory there. I could ask someone for
permission, but I'd rather not have to involve those people.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Standardizing file locations
- Posted by Matt Lewis <matthewwalkerlewis at g?ai?.com>
Jan 12, 2008
-
Last edited Jan 13, 2008
Robert Craig wrote:
>
> That sounds good.
> Keep in mind though that some people will want
> to use Euphoria on a shared host machine
> where they might not have permission to put stuff
> into /usr/share
>
> For instance, on both OpenEuphoria.org (Linux)
> and RapidEuphoria.com (FreeBSD) the
> /usr/share directory exists, but I don't have permission
> to create a subdirectory there. I could ask someone for
> permission, but I'd rather not have to involve those people.
Absolutely, but then you wouldn't install things there using the distro's
package manager. And there are all sorts of weird things you have to
deal with for web servers, anyway. This is basically an attempt to get
euphoria in line with the standard way of doing things--on Linux, for
now, but it'd also be cool to integrate with ports (?) eventually.
Matt
4. Re: Standardizing file locations
- Posted by Matt Lewis <matthewwalkerlewis at g?ail.c?m>
Jan 12, 2008
-
Last edited Jan 13, 2008
Robert Craig wrote:
>
> That sounds good.
> Keep in mind though that some people will want
> to use Euphoria on a shared host machine
> where they might not have permission to put stuff
> into /usr/share
>
> For instance, on both OpenEuphoria.org (Linux)
> and RapidEuphoria.com (FreeBSD) the
> /usr/share directory exists, but I don't have permission
> to create a subdirectory there. I could ask someone for
> permission, but I'd rather not have to involve those people.
Absolutely, but then you wouldn't install things there using the distro's
package manager. And there are all sorts of weird things you have to
deal with for web servers, anyway. This is basically an attempt to get
euphoria in line with the standard way of doing things--on Linux, for
now, but it'd also be cool to integrate with ports (?) eventually.
Matt
5. Re: Standardizing file locations
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.?om>
Jan 12, 2008
-
Last edited Jan 13, 2008
Robert Craig wrote:
>
> That sounds good.
> Keep in mind though that some people will want
> to use Euphoria on a shared host machine
> where they might not have permission to put stuff
> into /usr/share
>
> For instance, on both OpenEuphoria.org (Linux)
> and RapidEuphoria.com (FreeBSD) the
> /usr/share directory exists, but I don't have permission
> to create a subdirectory there. I could ask someone for
> permission, but I'd rather not have to involve those people.
Absolutely, but then you wouldn't install things there using the distro's
package manager. And there are all sorts of weird things you have to
deal with for web servers, anyway. This is basically an attempt to get
euphoria in line with the standard way of doing things--on Linux, for
now, but it'd also be cool to integrate with ports (?) eventually.
Matt
6. Re: Standardizing file locations
While most share hosting companies don't grant write permissions on such
directories, many of them let clients use package installers to install packages
within client space as long as packagers allow non-root installation and
relocation (i.e.: rpm ... --prefix=/non/standard/location) preserving this way
original distribution structure but under another directory.
JG
