To be specific on some of my issues with this Windows build stuff.
Main build system is autotools stuff, the MSVC stuff is separate and
needs maintaining separately. Due to a lack of interest or knowledge and
access to it some of the main developers do not work with this and so it
can get left behind. Its an uphill battle for anyone who wants to
maintain it because they will always be playing catch up. Also as it is
a second class citizen in the project features seem to be added on how
they will work with autotools and Linux before other platforms are
considered, causing more trouble for someone to maintain the MSVC build
files, the YAML test stuff is one such example.
This might be made a bit simpler by having widechar defined on its own
in a separate header file which is then included into the main API
header. At the moment should the API functions change then the .h.in
template in the main code needs changing and the header in the windows
directory would need changing as well. Separating out the widechar
definition would mean one common API header and only separate files for
defining widechar which is unlikely to ever change.
In the past I have spoke of the idea of going to a single cross platform
build system like scons, QMake or CMake, etc. This normally has not been
well recieved. Unfortunately without changes in LibLouis and
LibLouisUTDML these options are probably never going to happen. These
might be able to cope with some things like the .h.in template file,
scons I think can even create the config.h file, but none seem like they
will ever handle the GNULib stuff. I have done quite a bit of searching
online about using GnULib with other build tools but never found
anything worth while.
May be i was harsh in saying the attitude of the main developers is to
not care about anything other than autotools and not wanting to
compromise/cooperate with other build systems, it seems to be a trait of
those who still use autotools, any new build tool must work with my
autotools, I must never work with anything else because nothing seems up
to it or at least does not do it as autotools does.
Well done GNU on getting a loyal user base and effectively lock in (GNULib).
Anyone who does try and make LibLouis and LibLouisUTDML work on Windows
gets respect from me, as I have said things seem a bit stacked against
you with plenty of work to come in the future.
My final point is that if this stuff is not supported by the main people
working on LibLouis and LibLouisUTDML, then is something wrong in the
documentation in setting user expectations to high. If it is only
working purely through contributions, then might it be better placed in
a contrib directory so people know it is not a official project thing
and that it is seen as a second class citizen. Users expecting too much
is a big problem as it leads to disappointment and negative views.
Michael Whapples
On 06/06/2016 09:53, Arend Arends wrote:
I am using MSVC to produce a Windows version of LibLouis and LibLouisUTDML for our TactileView application, the latest versions are resp. 2.6.4 and 2.6.0 with some minor changes. So far I have managed to produce these following the directions, sometimes after making some minor changes to solve issues in the compilation procedure.
I would like to help to make a more standard compilation system based on Microsoft Visual Studio Community 2015, since this version is free for single users, but so far I did not find the time to integrate this all, so I am mostly still using an older version.
I also did not try to build newer versions of LibLouis(UTDML) since the work at the moment is mostly concentrated on the integration of the UEB work (I have expressed my concerns in the past about the integration, I am anxious to see the outcome).
Arend Arends
-----Oorspronkelijk bericht----- From: Davy Kager
Sent: Monday, June 6, 2016 10:06 AM
To: 'liblouis-liblouisxml@xxxxxxxxxxxxx'
Subject: [liblouis-liblouisxml] Re: Windows build
I use and build liblouis on Windows and have tried to make the yaml test suite work with MSVC. It looked promising but I never got it to work properly without spending a lot of time on it. I did update the NMake file (on the feature/ueb_update branch) and that works fine, but for testing I rely on Linux. I agree that this is far from ideal, and I would be happy to contribute where I can to make things easier for MSVC users.
-----Oorspronkelijk bericht-----
Van: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] Namens Christian Egli
Verzonden: maandag 6 juni 2016 9:48
Aan: liblouis-liblouisxml@xxxxxxxxxxxxx
Onderwerp: [liblouis-liblouisxml] Re: Windows build
On 06/03/2016 08:40 PM, Michael Whapples (Redacted sender mwhapples for
DMARC) wrote:
As for using the MSVC build files which should be the simplest route
for a Windows user, they do get broken from time to time because they
need to be manually maintained separately from the autotools stuff and
the main developers seem to not care about MSVC builds working. I
would go as far as to say that whenever it has been discussed to help
make it easier to build on Windows with MSVC, this has normally been
met with a lack of cooperation and attitude that every build system
should work around the autotools stuff and never the other way. Such
an approach will never lead to maintainers for Windows builds coming forward.
There are a number of issues:
1. liblouisutdml is basically unmaintained. I do apply patches once in a while but because I do not use it my interest is limited.
2. None of the current maintainers of liblouis use Windows so they rely on outside help to make it work on windows.
On the bright side I regularly build a mingw based binary of liblouis.
For msvc Bue has offered to maintain the needed header files in the windows subdirectory. And also AFAIK Bert has provided Docker recipies for both.
As for the current maintainers attitude, I can only say that I would like to keep things simple, maintainable, without too many #ifdefs and without having to cater to many different build systems. My time is limited and I would like to spend where my strengths are.
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
-----
Tag der offenen Tuer: Es war einmal...
Die SBS laedt Sie herzlich ein: 25. Juni 2016 von 9 bis 16 Uhr.
Mehr Informationen erhalten Sie unter www.sbs.ch/offenetuer
For a description of the software, to download it and links to
project pages go to http://liblouis.org
DISCLAIMER:
De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor de geadresseerde. Indien u niet de beoogde geadresseerde bent, verzoeken wij u vriendelijk dit aan de afzender te melden (of via: info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) en het origineel en eventuele kopieën te verwijderen.
The information sent in this e-mail is solely intended for the individual or company to whom it is addressed. If you received this message in error, please notify the sender immediately (or mail to info@xxxxxxxxxx<mailto:info@xxxxxxxxxx>) and delete the original message and possible copies.
For a description of the software, to download it and links to
project pages go to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
