New fork: Osmand Touch (for developers)

[Zsolt Bertalan]

The main reason for the fork were white spaces and the structure of the
project. I mindlessly use SHIFT+CTRL+F to format the files before I save
them. In this project you hardly find any formatted files (or at least
consistency), but if you format them, there will be thousands of changes
and my changes won't be accepted. Similarly with the structure: if I move
something, it will change dozens of dependencies, so my changes are not
accepted. My pull request were rejected, because they had too many changes.

This is somewhat understandable in itself, but the root cause is bad code
management and standard compliance. So I'm not only doing these changes to
make the app more useful to me, but also to demonstrate that the changes I
made are manageable and not detrimental but beneficial for the project.

There are a lot of other problems I want to address, but I expect that they
would be denied, because they have a domino effect like above and I would
touch too many files. A non exhaustive list:
- Some collection package names are in singular form, some abstract
class names are in plural form, there are misleading class names, method
names like an array of custom methods called onDraw(), the map layout
called main, the main layout called menu, and many other naming convention
errors.
- Some class instance names are particularly funny. E.g. the Thread
named run, or the intents which are consistently named indent.
- The development is totally opaque. You can't get information on what
is being developed. There are no meaningful commit messages, not to mention
issue/feature tracking. It's very hard to join in. I accidentally run into
Osmand Jira, but it's read only I guess, so it's not used as it should be.
Nothing links to there, only one guy mentioned it in pull requests recently.
- The code doesn't have too much comments. The wiki is not too
helpful. Documentation is lacking. The project has a very long and flat
learning curve.
- The build process is broken/not user friendly. The devs seemingly
don't use Eclipse or similar, only Notepad and they build with ant. The
code in the repo doesn't work in eclipse without tweaks. The project
structure is just bad.

Pull requests

At the moment I try to rebase my changes in the "touch" branch over the
master branch of the main project. This will rewrite the history of the
branch, so I can't accept pull requests. If you want to contribute, you
have to tell me first so that I stop committing and give you a commit as a
base for your fork. Don't worry, I work only sporadically, so usually you
can work and commit immediately.

Your thoughts?

[Carles Pina i Estany]

Hi,

At work sometimes we have a similar situation. When we have some of us
working on feature branches doing a refactoring might be inconvenient
for later on merging.

Perhaps this is the case in OsmAnd, where your changes would be accepted
but the timing was not convenient because it's leading to 1.8 or
something else?

Regards,

Post by Zsolt Bertalan
The main reason for the fork were white spaces and the structure of the
project. I mindlessly use SHIFT+CTRL+F to format the files before I save
them. In this project you hardly find any formatted files (or at least
consistency), but if you format them, there will be thousands of changes
and my changes won't be accepted. Similarly with the structure: if I move
something, it will change dozens of dependencies, so my changes are not
accepted. My pull request were rejected, because they had too many changes.
This is somewhat understandable in itself, but the root cause is bad code
management and standard compliance. So I'm not only doing these changes to
make the app more useful to me, but also to demonstrate that the changes I
made are manageable and not detrimental but beneficial for the project.
There are a lot of other problems I want to address, but I expect that they
would be denied, because they have a domino effect like above and I would
- Some collection package names are in singular form, some abstract
class names are in plural form, there are misleading class names, method
names like an array of custom methods called onDraw(), the map layout
called main, the main layout called menu, and many other naming convention
errors.
- Some class instance names are particularly funny. E.g. the Thread
named run, or the intents which are consistently named indent.
- The development is totally opaque. You can't get information on what
is being developed. There are no meaningful commit messages, not to mention
issue/feature tracking. It's very hard to join in. I accidentally run into
Osmand Jira, but it's read only I guess, so it's not used as it should be.
Nothing links to there, only one guy mentioned it in pull requests recently.
- The code doesn't have too much comments. The wiki is not too
helpful. Documentation is lacking. The project has a very long and flat
learning curve.
- The build process is broken/not user friendly. The devs seemingly
don't use Eclipse or similar, only Notepad and they build with ant. The
code in the repo doesn't work in eclipse without tweaks. The project
structure is just bad.
Pull requests
At the moment I try to rebase my changes in the "touch" branch over the
master branch of the main project. This will rewrite the history of the
branch, so I can't accept pull requests. If you want to contribute, you
have to tell me first so that I stop committing and give you a commit as a
base for your fork. Don't worry, I work only sporadically, so usually you
can work and commit immediately.
Your thoughts?
--
You received this message because you are subscribed to the Google Groups "Osmand" group.
For more options, visit https://groups.google.com/d/optout.

[Zsolt Bertalan]

It's not the timing, it's the amount of changes. I would do any kind of
inconvenient job for them (rebasing is very unconvenient, I can assure
you), but they simply don't want these kind of changes. They don't use
feature branches anyway, only a single development branch. I offered
merging my branch to a future dev branch.

I received some private messages. Sorry for not answering all of them. But
I can reflect here to some of the issues brought up.

Someone mentioned that maybe they are reluctant to accept the changes
because they want to protect the current licensing setup (your changes can
be used in proprietary licence, while Osmand code cannot). While this might
be true, I don't think it applies to this case and I don't have any problem
with this setup.
Another one: in open source projects it is the norm to allow whitespace
changes only on lines where the code changed. True, you shouldn't litter a
project with whitespace changes, but I could also do it in one commit with
the message "whitespace". That was my original plan. More than that, it's
not only single spaces, tabs, or extra lines. Most of the layout files for
example are illegible, because they aren't following guidelines and are
compressed like a JavaScript library. The project definitely needs a
cleanup.

[Marko Mäkelä]

Post by Zsolt Bertalan
Someone mentioned that maybe they are reluctant to accept the changes
because they want to protect the current licensing setup (your changes can
be used in proprietary licence, while Osmand code cannot).

IANAL, but I believe that it is the opposite. The fewer contributors a code
base includes, the easier it is to change the license. Some projects (such
as the GNU project and many projects driven by commercial companies)
require a copyright assignment for all contributed code, so that they are
free to change the license, or free to use dual licensing (such as
proprietary paid-for license, or GPL). If OsmAnd+ is linked with
GPL-incompatible libraries, such as some Google libraries (I do not know),
then the OsmAnd code that is used for compiling OsmAnd must be licensed
with something else than the GPL. The copyright holders are free to decide
which licenses to use.

Only if all copyright holders agree, the code can be relicensed. If anyone
disagrees, the code has to be removed. You might remember when the OSM data
was relicensed from CC-BY-SA to ODbL some time ago. The contributions of
those who did not agree to the license change were removed from the OSM
servers.

I guess that you only forked one of the 3 repositories so far? I do not see
any "core" or "resources" repositories included at the
https://github.com/herrbert74/Osmand.git repository. Technically, by
providing a compiled *.apk file without providing the corresponding full
source code snapshot (including build parameters), you may be violating the
GPL. See http://www.gnu.org/licenses/gpl-faq.html#SourceInCVS

Post by Zsolt Bertalan
Most of the layout files for example are illegible, because they aren't
following guidelines and are compressed like a JavaScript library. The
project definitely needs a cleanup.

Well, it definitely feels that OsmAnd is not following the spirit of free
software. The biggest issues (apart from refusing cleanup patches) seem to
be that the code is being scattered in 3 repositories, and the build
procedure is not documented. There are no source packages corresponding to
releases either. All this is alienating potential contributors, such as
myself. In the OSM domain, I have done some minor contributions to JOSM and
mkgmap in the past. They have a much lower barrier of entry, and
correspondingly more contributors and faster progress.

I would welcome a refactoring of the build system, with more options, and
using standard tools instead of shell scripts. I wonder what the standard
for NDK is. For pure C/C++ software, I believe that it would be CMake and
Make, or maybe a BSD/GNU compatible subset of Makefile if the NDK requires
a *nix system.

Ideally, the build should be modular so that you can select which features
you want to include. For example, I would want to exclude any Internet
connectivity and support for anything else than offline vector maps, and
maybe include extended heartrate/cadence sensor support.

Marko

[Sebastian Spaeth]

Post by Marko Mäkelä
Well, it definitely feels that OsmAnd is not following the spirit of free
software.

There might be an issue of bad code management, but please do NOT call
Osmand not following the spirit of free software, that is unfair!
What other Android Routing app is licensed under the GPL, has its code
developed commit-by-commit in the open in a public git repository?
What other Android Routing app provides you with regulary updated free
maps, where all the tooling to create you own maps is made public and
available under open source licenses too?
What other Android Routing app provides you with nightly builds (.apk
files) of both the "free" and the "paid" version?
What other Android Routing app allows distribution outside of the Google
store (e.g. on f-droid.org)?
What other Android routing app accepts pull requests for (some) fixes? I
had pull requests for routing improvements accepted in the past.
Call the flaws out, but not following the spirit of free software is not
one of them.

Sebastian
P.S. I am not affiliated with osmand.

[Osmandtrier]

Nice spirit and working shit. This sounds rude, but I did not update osmand
for one year. After updating I was happy that I have a backup of my old
version of osmand.

For example, it could happen, that the idea of a new routing don't work. In
this case it is very, very slow. But to remove the old routing API and give
the people a routing, what is not useable is stupid.

There are bugs, so I ask myself, how dumb must a developer be, to overlook
this bugs.

Reading Bertalan I have the feeling he share my point o view, there is a
good idea which will be ruined by the lousy working habbits of the
developers. They don't know, how to get a good quality standard.

I don't need a spirit, I want good work.

Post by Sebastian Spaeth

Post by Marko Mäkelä
Well, it definitely feels that OsmAnd is not following the spirit of free
software.

There might be an issue of bad code management, but please do NOT call
Osmand not following the spirit of free software, that is unfair!
What other Android Routing app is licensed under the GPL, has its code
developed commit-by-commit in the open in a public git repository?
What other Android Routing app provides you with regulary updated free
maps, where all the tooling to create you own maps is made public and
available under open source licenses too?
What other Android Routing app provides you with nightly builds (.apk
files) of both the "free" and the "paid" version?
What other Android Routing app allows distribution outside of the Google
store (e.g. on f-droid.org)?
What other Android routing app accepts pull requests for (some) fixes? I
had pull requests for routing improvements accepted in the past.
Call the flaws out, but not following the spirit of free software is not
one of them.
Sebastian
P.S. I am not affiliated with osmand.

[Marko Mäkelä]

Post by Sebastian Spaeth

Post by Marko Mäkelä
Well, it definitely feels that OsmAnd is not following the spirit of free
software.

There might be an issue of bad code management, but please do NOT call
Osmand not following the spirit of free software, that is unfair!
What other Android Routing app is licensed under the GPL, has its code
developed commit-by-commit in the open in a public git repository?

I do not think that the platform or the application domain is relevant for
this discussion.

That said, there is lot of free software related to viewing and editing
maps and routing, and there is a lot of free software for Android. Much of
it is being stored in a publicly accessible repository during development.
Yes, typically it is "a repository", not multiple ones, unless the software
is depending on third-party libraries that are also under development.

A common practice when using multiple repositories is to pin the foreign
repository version, for example in Subversion by setting the svn:externals
property. For example, if software X is using repositories X,Y,Z, and the
software revision is 1234 in the "main" repository X, then repository X
revision 1234 would refer to speicific revisions of repositories Y and Z.
There would be no guessing how to fetch the exact source code revisions
used when building the binary package.

I find that the way how OsmAnd is hiding the build parameters and the
actually used repository revisions of *.apk files is slightly violating
http://www.gnu.org/philosophy/free-sw.html Freedom 1: "The freedom to study
how the program works, and change it so it does your computing as you wish."

Usually in free software projects, you can download a source package, which
contains instructions on how to build it. Alternatively, you can check out
the source repository and easily build the code, by using some common
procedure. This is not the case with OsmAnd. You have to check out 3
independent repositories, hope that they are in sync with each other, and
then execute some shell script in a well-hidden subdirectory. For a random
potential contributor, the barrier of entry is greater than necessary. Why
does the wiki page
https://code.google.com/p/osmand/wiki/InstallDevelopmentEnvironment mention
that Eclipse is needed, when the code builds fine without it? And why is
there not a single ant invccation to build all the code (including the
native code)?

If the build system and the use of repositories were more conventional,
OsmAnd could get more contributors.

Marko

[Pere Pujal i Carabantes]

El dt 15 de 07 de 2014 a les 23:02 -0700, en/na Sebastian Spaeth va

Post by Sebastian Spaeth
What other Android Routing app is licensed under the GPL, has its code
developed commit-by-commit in the open in a public git repository?
What other .....

Navit?
www.navit-project.org
I used it in the past in my Tomtom and performed quite well.
Later I switched to an Android tablet and I prefered Osmand over Navit,
mainly because Osmand were able to display raster maps, so I have the
functionallity of Navit + Ttmaps in one app.

[c***@public.gmane.org]

Some observations from a interested bystander:

Op vrijdag 11 juli 2014 15:28:33 UTC+2 schreef Zsolt Bertalan:

The main reason for the fork...


I wouldn't use the word "fork" lightly. With a fork comes all kinds of
downfall and aftermath you may not be able to address, not willing to, or
did not anticipate for.
It would be an awful waste of your talents and contributions to see you
take a hike and than no one would be interested to follow you. Be careful
what you wish for.

...but the root cause is bad code management and standard compliance.
Unless you know the historic path of the code and also were involved
yourself in this, this statement appoints blame and is presumptuous. It
would have rubbed me backwards if I were to be on "the other side".

There are a lot of other problems I want to address (...). A non exhaustive
This is a serious list of issues indeed. You are well to address these for
improvement.

Your thoughts?
You are raising valid points. Following this thread a bit, I am missing the
reaction/position of the core dev team. That might simply be a holiday
season thing. But I think an open, respectful and positive discussion would
be rather valuable.

Ceaus

[Harry van der Wolf]

I have followed this as well. Zsolt has some good points. Some points are
also personal taste.

He mentions that he created a couple of pull requests and that not a single
one was accepted due to the thousands of changes by the autoformatting with
Shift+Ctrl+F. This is really an Eclipse "thing". If you don't work in
Eclipse but in a standard editor, or you create direct pull requests from
the forked GIT web pages you can't even do this.

I can see his goal in producing nicely formatted code, but to improve the
code and add your own changes it is definitely not necessary.
If adding the useful changes to the code and put these in a pull request,
without all the formatting, they might have been accepted. The core dev(s)
also need to check what code is added to the project. If you see thousands
of code lines it is extremely difficult, even impossibile, to see what the
real code changes are. I would not accept that either.
Adding functional changes and bug fixes to code is one thing.
Creating nicely formatted code is another thing. For me there is a clear
priority difference in both.
From my perspective, and from the perspective of the projects I worked in
(and none of them was java, all C/C++ and python), it is wrong to mix "code
cleaning" changes with functional changes/bug fixes. Do this only if you
are the only developer, not if a team of developers is working on the code
which is often the case and certainly on OS where devs from all over the
world without weekly progress meetings are working on the code.
So I would create a functional/bugfix request with a proper description,
and I would add a second pull request containing the auto formatting, and
only the auto formatting and describe it like that. This is a bit more
work, but in a team the only way to work (again in my perspective).

Another point is maybe that the core devs were really working towards a new
release, which would (again in my perspective) require a new development
branch in this case to be merged later with the default branch after the
release: 1.82 in this case.

I agree that the devs are not always responding in time, but this is also
due to the fact that they really work their asses of to work on all new
functionality and bug fixes. I also think that the devs are sometimes
working on new ideas which they think are interesting which might not be
interesting for the bigger community, but that's also how it works in
projects with so few devs.

I think this project is that complex that it needs a change manager and a
release manager (could be one person), to coordinate and prioritize
everything (and no: I'm not volunteering).

I sincerely hope that Zsolt's insights and knowledge will be profitable for
the main project, but I'm afraid this is not the right path for it.

Harry

Post by c***@public.gmane.org
The main reason for the fork...
I wouldn't use the word "fork" lightly. With a fork comes all kinds of
downfall and aftermath you may not be able to address, not willing to, or
did not anticipate for.
It would be an awful waste of your talents and contributions to see you
take a hike and than no one would be interested to follow you. Be careful
what you wish for.
...but the root cause is bad code management and standard compliance.
Unless you know the historic path of the code and also were involved
yourself in this, this statement appoints blame and is presumptuous. It
would have rubbed me backwards if I were to be on "the other side".
There are a lot of other problems I want to address (...). A non
This is a serious list of issues indeed. You are well to address these for
improvement.
Your thoughts?
You are raising valid points. Following this thread a bit, I am missing
the reaction/position of the core dev team. That might simply be a holiday
season thing. But I think an open, respectful and positive discussion would
be rather valuable.
Ceaus
--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Zsolt Bertalan]

Marko:
I would move every project into a separate repository and I would rename a
few of them, because the names are misleading. I wouldn't put feature
options into the build system, I think they are in the right place in the
app. But otherwise I agree, we need a flexible, transparent, easy to use
build system. That will be Android Studio and Gradle. There are two
problems with that. I have no experience with them (and the NDK) and I
think they will break what I currently do: the rebasing process. For now I
focus on the UI, but this should be a long term goal.
Ceaus:
The history path is easy to follow in git, but the problems I found are
fairly static and solid. I hope I didn't insult anybody and I hope we will
get to know their opinion.
Harry:
My very first pull request was pure refactoring. After a while I had the
feeling that he wouldn't accept these kind of changes at all. And don't
forget that not all whitespace problems were cosmetic. A lot of the xml
files (mainly layout files and even the manifest!) are unreadable. I just
refuse to work under these circumstances, but at the same time I want to
fiddle with it. That's what I do now, that's why I use the word fork
lightly.
I agree that gradual formatting of the code base is not the right thing to
do. I should do one or a few big refactoring commit(s). But again, this
would totally break the rebasing, what I do now, so I have to wait a bit
with that, until I'm more comfortable with the codebase, the dependecies
and the structure of the project. When I get there, we will see. If they
would say they would accept my refactoring changes, I would gladly do the
big one.

[Marko Mäkelä]

Post by Zsolt Bertalan
I would move every project into a separate repository and I would rename a
few of them, because the names are misleading. I wouldn't put feature
options into the build system, I think they are in the right place in the
app.

Sure, the default build could include all features like they currently are,
and let them to be enabled or disabled at runtime.

I think that an important aspect of open source is that you can compile
custom binaries, choosing features at build-time. Many people are compiling
custom maps from OSM data, for example with mkgmap for Garmin devices. I
guess that a few people are compiling their own OsmAnd maps too, perhaps
omitting features that are not of any interest to them. It would be nice to
be able to do the same thing with OSM-related applications. For example, I
would want to build an "OsmAnd-" that does not require any permission (or
code) to access the Internet.

But otherwise I agree, we need a flexible, transparent, easy to use build

Post by Zsolt Bertalan
system. That will be Android Studio and Gradle. There are two problems with
that. I have no experience with them (and the NDK) and I think they will
break what I currently do: the rebasing process. For now I focus on the UI,
but this should be a long term goal.

Gradle is already packaged by Debian and probably other GNU/Linux
distributions, so it should be painless to use. I hope that it can handle
build-time configuration parameters and NDK code, and that it supports
parallel compilation, like make -j$(nproc).

Being an old-school *nix user, I would appreciate it if the package can be
also built without using a modern IDE, such as Android Studio or Eclipse.
Emacs for the win. :) Of course, it does not hurt to include some
up-to-date "project files" for modern IDEs, for those people who prefer to
use them.

It would seem to me that the build system refactoring could be done in a
separate branch. Maybe you could create a pull request for it? The old
build system could coexist with the new one for a while.

Post by Zsolt Bertalan
The history path is easy to follow in git, but the problems I found are
fairly static and solid. I hope I didn't insult anybody and I hope we will
get to know their opinion.

I hope that the fork can be avoided. I too hope I did not insult anybody
when criticizing the current layout of the repositories and the build
system.

Reformatting files will create huge diffs, which can be a pain to review.
At work, I have developed some ways to review such diffs. I write a custom
transformation script, and run both versions of the files through it, and
then compare the result. This would show only the essential differences.
For example, you could write a converter that replaces each space or TAB
with a newline, and then compare the two sets of files, ignoring empty
lines. If there is no other change than white-space, there should be an
empty diff after the transformation. To ease the reviewers' work, I would
not combine any non-mechanical changes with large mechanical changes, not
even minor typo-fixes in comments. Those can be done in a separate commit.

It would seem to me that you should try to get the reformatting changes
accepted, to minimize the diff between the main OsmAnd tree and your
branch. At work, I have learned the hard way that it is bad to do too many
changes in a feature branch. But, I guess we would need some feedback from
one of the core developers that some reformatting can be accepted in
general.

Marko

[Harry van der Wolf]

Post by Marko Mäkelä
Being an old-school *nix user, I would appreciate it if the package can be
also built without using a modern IDE, such as Android Studio or Eclipse.
Emacs for the win. :) Of course, it does not hurt to include some
up-to-date "project files" for modern IDEs, for those people who prefer to
use them.

I'm also and old-school *nix user (since '89). For me a bare-bones
command-line option is really a requirement, not an option. I don't care if
it's make, cmake or some shell script.

Harry

[RogerE]

The biggest problem right now for potential new contributors is that it is
very difficult to set up the development environment and build the code.
The development environment How-To Wiki page is out-datet and is not of any
help for the current code. It used to be reasonably easy up until about a
year ago - just import the code into Eclipse, build, download and run, but
not any more.

Even if the code structure is not optimal as is, it will be a really useful
step forward if someone with the knowledge would take the time to write a
step-by-step guide on how to set up the development environment and build
the current code (or even better update the Wiki How-To).

Roger

[Harry van der Wolf]

I updated the wiki specifically for this reason to add the "Terminal based
compilation on Linux or Mac OS X".
Is that too short? (no pun intended)

Post by RogerE
The biggest problem right now for potential new contributors is that it is
very difficult to set up the development environment and build the code.
The development environment How-To Wiki page is out-datet and is not of any
help for the current code. It used to be reasonably easy up until about a
year ago - just import the code into Eclipse, build, download and run, but
not any more.
Even if the code structure is not optimal as is, it will be a really
useful step forward if someone with the knowledge would take the time to
write a step-by-step guide on how to set up the development environment and
build the current code (or even better update the Wiki How-To).
Roger
--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[RogerE]

Harry,
I tried your command line guide and after some fiddlin' the code does
indeed compile and run, but it don't seem to include the native code
(tested on a Galaxy S5). The apk file is also smaller than the nightly
build, 20.7MB vs. 27MB (OsmAnd-master-nb-2014-08-01.apk). Maybe the guide
really is too short then...

Roger

Post by Harry van der Wolf
I updated the wiki specifically for this reason to add the "Terminal based
compilation on Linux or Mac OS X".
Is that too short? (no pun intended)

Post by RogerE
The biggest problem right now for potential new contributors is that it
is very difficult to set up the development environment and build the code.
The development environment How-To Wiki page is out-datet and is not of any
help for the current code. It used to be reasonably easy up until about a
year ago - just import the code into Eclipse, build, download and run, but
not any more.
Even if the code structure is not optimal as is, it will be a really
useful step forward if someone with the knowledge would take the time to
write a step-by-step guide on how to set up the development environment and
build the current code (or even better update the Wiki How-To).
Roger
--
You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Harry van der Wolf]

OK,

I will write a longer version. I will split up the original part from "my"
very small addition and rewrite it as a complete new article like "Install
terminal commandline build environment on Linux/OS X" (or something like
that. The title is not so catchy).

It should be there next weekend. Probably Wednesday evening (Dutch time
zone :) )

Harry

Post by RogerE
Harry,
I tried your command line guide and after some fiddlin' the code does
indeed compile and run, but it don't seem to include the native code
(tested on a Galaxy S5). The apk file is also smaller than the nightly
build, 20.7MB vs. 27MB (OsmAnd-master-nb-2014-08-01.apk). Maybe the guide
really is too short then...
Roger

Post by Harry van der Wolf
I updated the wiki specifically for this reason to add the "Terminal
based compilation on Linux or Mac OS X".
Is that too short? (no pun intended)

Post by RogerE
The biggest problem right now for potential new contributors is that it
is very difficult to set up the development environment and build the code.
The development environment How-To Wiki page is out-datet and is not of any
help for the current code. It used to be reasonably easy up until about a
year ago - just import the code into Eclipse, build, download and run, but
not any more.
Even if the code structure is not optimal as is, it will be a really
useful step forward if someone with the knowledge would take the time to
write a step-by-step guide on how to set up the development environment and
build the current code (or even better update the Wiki How-To).
Roger
--
You received this message because you are subscribed to the Google
Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[RogerE]

Thanks Harry, the command line guide is easy to follow now, but the native
code still don't seem to be included correctly. The "old-ndk-build.sh"
command ends with one of the expected lines and the apk contains the
expected "libgnustl_shared.so" file. The nightly build apk does however
include a file named "libosmand.so", wich is missing in the new build - so
something isn't quite right. I use sdk_r23.0.2-linux and ndk-r9d.

I did also initially run into another problem: the "old-ndk-build.sh"
command ended with one of the expected lines indicating successful
completion, but when looking trough the log it contained a fault message:
"..../functions.sh: line 107: svn: command not found". Apparently, svn is
also needed and when installed everything built without errors. I guess the
guide should also include a statement about svn.

Roger

Post by Harry van der Wolf
OK,
I will write a longer version. I will split up the original part from "my"
very small addition and rewrite it as a complete new article like "Install
terminal commandline build environment on Linux/OS X" (or something like
that. The title is not so catchy).
It should be there next weekend. Probably Wednesday evening (Dutch time
zone :) )
Harry

Post by RogerE
Harry,
I tried your command line guide and after some fiddlin' the code does
indeed compile and run, but it don't seem to include the native code
(tested on a Galaxy S5). The apk file is also smaller than the nightly
build, 20.7MB vs. 27MB (OsmAnd-master-nb-2014-08-01.apk). Maybe the guide
really is too short then...
Roger

Post by Harry van der Wolf
I updated the wiki specifically for this reason to add the "Terminal
based compilation on Linux or Mac OS X".
Is that too short? (no pun intended)

Post by RogerE
The biggest problem right now for potential new contributors is that
it is very difficult to set up the development environment and build the
code. The development environment How-To Wiki page is out-datet and is not
of any help for the current code. It used to be reasonably easy up until
about a year ago - just import the code into Eclipse, build, download and
run, but not any more.
Even if the code structure is not optimal as is, it will be a really
useful step forward if someone with the knowledge would take the time to
write a step-by-step guide on how to set up the development environment and
build the current code (or even better update the Wiki How-To).
Roger
--
You received this message because you are subscribed to the Google
Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Harry van der Wolf]

Hi Roger,

I will answer in "Build OsmAnd from the command line (Was: New fork: Osmand
Touch (for developers))
<https://groups.google.com/forum/#!topic/osmand/yTJXIOxgY4s>" as not to
hijack this thread any further.

Harry