May be I am, but that might be down to my view of who the direct
LibLouis user will be. I see LibLouis as a library, which is used in
applications, and the people creating those applications are application
developers so will have developer skills.
Users as you term them, I think would be looking to use applications
rather than LibLouis. As an example one such application would be
BrailleBlaster.
These app developers should provide binary appbundle distributions of
their apps, this would be simple enough for any Mac user to install/use.
I still believe installing in /usr/local on a Mac is bad, you never
dealt with the question of the various compile options and how that
should be handled. The most concerning of them being whether a
/usr/local install should be compiled for UCS2 or UCS4. In the worst
case should a program expecting a UCS4 build of liblouis get a build
compiled for UCS2 then the software can just crash without any useful
error message.
As I said table developers are a slight exception as some of the
liblouis tools may be useful. Either they need to learn how to compile
LibLouis (which isn't the hardest thing and possibly something they may
want to learn anyway so they can build from GIT), or alternatively may
be a LibLouis tools appbundle needs creating which when launched would
open a terminal setting it up to use LibLouis from the appbundle.
Compiling LibLouisUTDML is a totally different matter and can be quite
complicated. However I think many of the arguments of supplying end
users with appbundles of applications still holds.
Michael Whapples
On 04/09/2015 14:53, Gregory Kearney wrote:
All that would be fine, if you could ever get liblouisutdml to actually build
and install which of course you can't even with homebrew or any other method.
Even homebrew is left trying to instal an old version of liblouisutdml 2.5.0.
So your saying here you would rather that users have no access to liblouis at
all? Because right now that is the choice we have to make. I can easily check
for its existence and make sure I am not over writing a newer version. But to
expect everyone be have developer skills, and I am an experienced MacOS user,
is simply not realistic.
A developer would still be free to build out his own version and put it in the
app bundle if they wanted to. No one is forcing them to us the pre-built
binaries if they choose not to and if they were ever able to get liblouisutdml
to actually build. All I'm asking is a pre-built binary distribution that I
could use in the standard location. If others chose to build special versions
for their app bundles let them.
By the way I too almost always use the full path to a table.
Commonwealth Braille & Talking Book Cooperative
Greg Kearney, General Manager
#320, 185-911 Yates Street
Victoria, BC V8V 4Y9
CANADA
Email: info@xxxxxxxxx
U.S. Address
21908 Almaden Av.
Cupertino, CA 95014
UNITED STATES
Email: gkearney@xxxxxxxxx
On Sep 4, 2015, at 6:41 AM, Michael Whapples (Redacted sender "mwhapples@xxxxxxx" forFor a description of the software, to download it and links to
DMARC) <dmarc-noreply@xxxxxxxxxxxxx> wrote:
That though comes with so many issues in itself.
An app developer want to use LibLouis in their app, how do they depend on the
install in /usr/local? Do they ship a copy of the binaries with their app and
install it in /usr/local? If say I wrote an app which did that as part of its
install, what should the installer do if it finds an existing installation?
What happens when the user wants two apps which use two different versions of
liblouis but those versions are not compatible in the API? Even if the apps use
the same version, what if one depends on LibLouis using UCS2 and another
depends on LibLouis using UCS4?
OK, so may be the app doesn't ship liblouis, then it needs code to detect when
liblouis is not installed and handle that.
Linux is a slightly different case as most distributions use package managers
like apt, yum, pacman or something else which handles all these dependency
issues. MacPorts, HomeBrew and other similar systems are package managers for
MacOSX, the problem being that none of them are official package managers which
come with the OS.
It really is so much better if the app developer includes liblouis within their
app bundle. There is fairly little reason for end users to install liblouis on
its own, the only case I can think of being table editors.
This is how Windows has dealt with the issue of conflicting versions of
libraries without a package manager in the OS, every application has its own
local set of libraries. I thought generally that was how MacOSX dealt with it
as well with the appbundle.
Michael Whapples
On 04/09/2015 14:29, Gregory Kearney wrote:
I have to disagree here, and strongly. There is a standard location in theFor a description of the software, to download it and links to
MacOS to install all these files. /usr/local/ and it's related subdirectories.
A prebuilt liblouis and more important a prebuilt liblouisutdml with it's
file2brl program, the most recent version of which has resisted every effort I
have made to build it, would go a long, long way in in making liblouis more
useful. With such a prebuilt set of binaries and libraries I could build an
installer that would place it into the /usr/local/ path. From there I and
others could then depend on it being there to call it's functions in our human
UI programs.
It is simply way to much to expect your average user, even those with command
line background to 1. install all the developer tools needed, 2. configure,
build and install the software from source. Particularly when, as in the case
of liblouisutdml it will not build cleanly out of the box.
Tools like homebrew can do this but that still demands the end user to install
the development environment and even then liblouisutdml fails to build. So a
binary build that expects it files to be placed into /usr/local/ paths would be
the answer, no need to install extra software, no need for our end users to
know about building software MacOS installers could simply install it while
installing the human interface in /Applications directory.
Please, for the love of god, do this. There are so many things I could do with
liblouis and liblouisutdml if I could but only get a reliable method of
installing binary packages of the latest versions into /usr/local/
Commonwealth Braille & Talking Book Cooperative
Greg Kearney, General Manager
#320, 185-911 Yates Street
Victoria, BC V8V 4Y9
CANADA
Email: info@xxxxxxxxx
U.S. Address
21908 Almaden Av.
Cupertino, CA 95014
UNITED STATES
Email: gkearney@xxxxxxxxx
On Sep 4, 2015, at 4:09 AM, Bert Frees <bertfrees@xxxxxxxxx> wrote:For a description of the software, to download it and links to
Hi Michael,
I agree.
Actually the table paths can be relative on all platforms, also Mac OS. And I
don't even think any special code was needed to accomplish that. The command
line tools just work as long as you specify the (relative or absolute) path to
the table, if you just specify the table name liblouus will not find the
table. The way I'm using my prebuilt liblouis binaries in my application is by
always specifying absolute table paths.
Michael Whapples writes:
I am not really sure whether it would be useful for MacOSX consideringFor a description of the software, to download it and links to
certain things in the build process and what one gets out.
The main thing which comes to my mind is that the default table path
gets hard coded into liblouis by the compile process, so if I were to
compile liblouis on my system to have a table path of
/Users/mwhapples/my_tables, then my build of liblouis is almost
certainly not going to work on anyone elses system.
I think something similar happens with the command line tools of
liblouis and where they look for the liblouis library.
OK, I could use some fairly generic type path like
/usr/share/liblouis/tables which installing the binary build could
create and place the tables in, but that in itself is a bit wrong on the
Mac as it would require an installer rather than distributing an
appbundle and would mean writing files into system directories.
LibLouis itself is not an end user tool and in my mind its really for
the end user application developers to create a suitable binary
distribution. As an example my JLouis java bindings for LibLouis does a
certain amount of work to allow the Java application to set the table
path (and if they are not I could get the JLouis bindings to default the
path to somewhere relative to the JLouis JAR should the application not
set a table path). This is something which the command line tools of
LibLouis do not do and so lower their suitability for portable
redistribution in binary form.
It is worth noting that I seem to remember there being special code in
LibLouis which makes the table path relative for Windows binaries. May
be this should also be the case for MacOSX. If that were done then it
would be more suitable for binary distribution.
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
project pages go to http://liblouis.org
