[BRLTTY] Compiling BRLTTY for Android on Windows

[Dave Mielke]

[quoted lines by Robert Pösel on 2018/03/08 at 18:55 +0100]

>from your reply I feel some defensive attitude, 

No, I don't get defensive. That's never been my style. What is my style, 
hwoever, is to be very direct. Perhaps, fotr those who aren't used to it, this 
can be misinterpreted as being defensive.

>so I assure you my message wasn't intended to push you into something. It was 
>more like sharing my experience from trying to build on Windows and ideas that 
>might help with that.

Yes, I undestand. My opposing positioin, though, is that we build on Linux, and 
that we support a way to build on Windows for Windows. I don't personally see a 
good reason to put in a lot of effort to change things just so that someone can 
build on Windows for a non-Windows platform. Maybe, if the need for so doing 
increases, I might begin to see an actual need. For now, I think it makes more 
sense for a Windows person to set up a Linux VM just like how I run a Windows 
VM on Linux for times when I need to do things that way around.

>Well, I understand CMake as a multiplatform tool, definitely not a
>Windows-specific tool. On CMake about page
>(https://cmake.org/overview/) they say:
>/
>"CMake is an extensible, open-source system that manages the build
>process in an operating system and in a compiler-independent manner.
>Unlike many cross-platform systems, CMake is designed to be used in
>conjunction with the native build environment. Simple configuration
>files placed in each source directory (called CMakeLists.txt files)
>are used to generate standard build files (e.g., makefiles on Unix
>and projects/workspaces in Windows MSVC) which are used in the usual
>way. (...)"
>/

Sure, but just because they make that claim doesn't make it so. I just checked 
on my newest Linux system and cmake isn't on it. Yes, it has been packaged and 
I could install it, but that's far from the default on Linux.

One must bear in mind that brltty is designed to be built by regular users - 
not just by skilled developers. We want it to be easily available to everyone 
so it's been designed so that an average non-developer user can build it with 
very little effort. I've no desire to chagnne this.

Of course, when I say this, I mean building for Linux on Linux, building for 
Windows on Windows, etc. Building for a non-native platform is, by definition, 
more complicated. For Android, my preference is to favour building on Linux 
since that's what we ourselves primarily use.

>I saw various multiplatform projects using CMake and also on their website 
>they mention projects like MySQL or KDE are using it too. Since it's so 
>popular and makes building multiplatform projects much easier, I ////wanted to 
>know whether you thought about it.

Most users of those tools don't rely on them in the same way as a braille user 
relies on brltty. For us, brltty is as important as the screen itself. Without 
it, we have no screen and the system is unusable. This means that our users 
include a lot of people who simply don't have, don't want to have, and 
shouldn't need to have a great degree of technical skill. They simply want to 
get on with their lives, having their "screens" work with as little effort as 
possible. Try to imagine how you'd feel if, in order to use your computer for 
the most basic things, you'd need to perform a complicated build process to get 
your screen to work first.

>I understand that when something works it's better to keep it that way and 
>don't change things without proper reason.

I go further than that. I simply don't want to risk introducing needless 
glithces into the brltty build process unless it's absolutely necessary. If a 
braille user encounters a nedlessly introduced glitch, he may even find that 
it's become impossible for him to let us know about it. For him, it's not as 
easy as just finding some other computer that works. No matter which computer 
he's using, he still needs his braille device to work on it.

>can you please tell me where can I find list of source files
>from which is libbrltty_core.so compiled?

There's no such explicit list as it's all derived from the #include 
dependencies. We just make what needs to be made by specifying the top-level 
items. I wouldn't even want to try to maintain an explicit list as it'd become 
out-of-date a day or so after it was constructed. :-)

>Google maintains backward compatibility with older Android versions,
>so you don't need to use older build tools to support older Android
>versions. You can use latest version of SDK / build tools and still
>keep BRLTTY app working on Android 4.0 (by setting minSdkVersion
>value).

That's not quite true. Building for something that's sufficiently old usually 
requires including a support library which contains similar, but not quite the 
same, compatibility objects. There's also the Java 7 versus Java 8 issue, which 
isn't as easy to surmount as one would hope.

>On the other hand, using old SDK / build tools might cause problems
>on newer Android versions, as we've seen with the "native text
>relocations" error recently.

And upgrading to the latest NDK absolutely wasn't straight forward. While I 
didn't say anything, I definitely did have problems. Things failed to compile. 
After I had them compiling again, they didn't install due to functions now 
being defined in the newer headers but not yet implemented within the 
libraries. After resolving those, I found that brltty would no longer install 
on older releases of Android. It took some research and trickery to resolve 
that one. Now, finally, yes, it's all working again, but that didn't come very 
easily.

>Google previously used Eclipse as main IDE and Ant as build system.
>Few years ago they created Android Studio and since then they use
>Gradle as build system. With Gradle it is easier and also more
>powerful to build Android projects.  And as I mentioned in last
>e-mail, they even removed the Ant build scripts from SDK last year,
>so they expect everyone switching to Gradle eventually. For building
>native code via NDK they use CMake - Gradle will run that CMake
>script to compile and get binaries which then Gradle builds into
>resulting APK. That's why I mentioned that (from this point of view)
>it would be best if whole BRLTTY would use CMake too (but I'm not
>saying it should).

Sure, if we were only discussing building for Android. Why, though, would I 
want to optimize for building on Android when we have plenty of Linux users who 
need to build brltty for themselves and we already always provide an up-to-date 
Android apk which contains our latest changes?

>>My question is: Rather than introduce a bunch of needless and
>>unwanted turbulence into our way of building, why not just install a Linux VM
>>on Windows and do it our way?
>Because since I already spent some time trying to make it work, I
>thought that finishing it and finding working solution for building
>on Windows would also help others who may want to do the same thing
>in the future.

I'm sure I would were I to perceive the need - but I don't. Maybe I'm just not 
getting it. My position is that the life of a regular user should be easy even 
if it means that a developer or two need to put in a bit of extra effort.

-- 
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke           | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: 1-613-726-0014 | Canada  K2A 1H7   |