[01:22:17] *** Quits: Horwitz (~mich1@p200300ec9f036e00022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
[01:34:59] *** Joins: Horwitz (~mich1@p200300ec9f01cd00022268fffe64e7c4.dip0.t-ipconnect.de)
[01:34:59] *** ChanServ sets mode: +o Horwitz
[10:08:12] <jkoan> mvglasow: i think the problem is that we are running with the cmake from the host and not the cmake from android at file build_android.sh Line 31. This creates a config where some host variables are contained. Probably its enough to just run cmake from gradle and never ever need to use build_android.sh after we have adjusted some things at build.gradle like the source clobbering.
[16:15:28] <mvglasow> jkoan that is indeed a question I had: why are we running cmake twice, i.e. once in the script and once inside build.gradle?
[16:17:25] <mvglasow> however, I'm not sure results depend on which cmake instance runs, as presence of libraries is detected via pkg-config
[16:17:54] <mvglasow> and pkg-config is controlled via environment variables telling it where to look for libraries
[16:19:08] <jkoan> the easy answer would be "bacause its wrown like this" but i really much hate this answer, so the better answer is because within the migration from the ant based solution we never made the solution to work with only gradle. And i even thought that it could possibly not be possible, but now with more knowlage i think it is and also made some stept in this direction
[16:20:22] <jkoan> for pkg-config, i made it simple and disabled everything related to it when android is detected within the CMakeLists.txt
[16:21:53] <mvglasow> what I meant is, do we really need to run cmake twice? what if we just skipped the first run, would the build still produce something useful? or do we need to fix something before?
[16:22:40] <jkoan> i think i do have it working with gradle with only one cmake run, except the image generation
[16:23:31] <jkoan> ah and traffic/null did had problems when i tried, but i need to take a look at it again
[16:35:31] <mvglasow> yea, image and XML generation still relies on make and takes place outside gradle
[16:41:17] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 260 seconds)
[16:54:34] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt)
[17:06:31] <jkoan> on make or cmake?
[17:15:15] <mvglasow> the Android build uses make to build images, translations and XML
[17:16:04] <mvglasow> I wonder how this is done on other platforms, I see the Linux build script runs cmake first, then make, so which of these two generates these files there?
[17:20:14] <Navit> <jkoan> Cmake generates the makefiles
[17:21:11] <Navit> <jkoan> But with gradle I think ninja is used instead of make
[17:35:15] <mvglasow> ok, something to clean up for later
[17:35:46] <mvglasow> in the meantime I might have solved the issue of CMake complaining about no C++ compiler being found
[17:35:54] <mvglasow> as for the F-Droid build issue:
[17:36:15] <Navit> <jkoan> Do you have the code uploaded somewhere?
[17:36:26] <mvglasow> coming soon :.)
[17:37:13] <mvglasow> both instances of CMake report all environment variables (CMAKE_SYSROOT, PKG:CONFIG_DIR, PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSROOT_DIR) as empty
[17:37:34] <mvglasow> and the CMake version invoked by gradle is 3.6.0-rc2, should be the one from NDK
[17:37:52] <mvglasow> also I get a CMake Warning at /opt/android-sdk/ndk/22.0.7026061/build/cmake/android.toolchain.cmake:453
[17:38:47] <mvglasow> so the CMake instance from NDK is getting used as far as I can tell, but pkg-config is acting weird
[17:50:35] <mvglasow> in the meantime...
[17:50:57] <mvglasow> PR for the CXX not found fix is in preparation, just waiting for CI to finish
[17:51:53] <mvglasow> also I have managed to merge the two build.gradle instances into one single file in the project root, which helps with package name detection in F-Droid CI
[18:00:11] <mvglasow> the CXX pull request is at https://github.com/navit-gps/navit/pull/1092
[18:01:08] <mvglasow> and with these two, F-Droid CI finally works as intended, i.e. up to the same bittiness mismatch error as the real F-Droid
[18:04:29] <jkoan> so only c++ is the problem?
[18:15:29] <mvglasow> once the CXX thing is fixed and build.gradle is consolidated into one file, we'll still have to fix the library misdetection issue and it might work... or we might hit the next bug, but I don't wanna come across as pessimistic :->
[18:16:03] <mvglasow> for build.gradle I'm still awaiting CI results, then there'll be another PR
[18:19:03] <mvglasow> here it is: https://github.com/navit-gps/navit/pull/1093
[18:19:24] <mvglasow> which leaves us with the bittiness issue on Android
[18:20:36] <jkoan> https://gist.github.com/jkoan/0dbbb428a8ba1570d419676fd725b002 this i my messey CMakeLists.txt which should fix the problem about pkg-config
[18:20:50] <jkoan> and with that the bittiness issue
[18:21:18] <jkoan> just ignore all the irrelevant crap
[18:22:10] <jkoan> binfile2 is a research rewrite where i am currently rewriting the binfile plugin but with libzip
[18:26:30] <jkoan> mvglasow: i will merge your PRs with Admin rights as they dont produce builds due to the ciecleci issue. We will fix everything what evantually comes up later on. The app won't be usable any way because the images would be missing
[18:28:07] <mvglasow> hold on.. images missing, where?
[18:29:08] <jkoan> images will be missing when only gradle is run because of "assets.srcDirs = ["navit/android/assets"] "
[18:29:22] <mvglasow> I tried #1093 locally and the bitmap images were there, if that's what you mean... unless master has changed over the past week
[18:30:01] <jkoan> but you have used build_android.sh right?
[18:30:13] <mvglasow> ah... I didn't touch build_android.sh, fir now this is still the entry point
[18:30:37] <mvglasow> all the gradle PR does is merge two files into one and ditch the include
[18:30:40] <jkoan> yes, but my end goal of this weekend is to build android with just gradle
[18:30:59] <jkoan> yes, i understood both PRs ;-)
[18:31:14] <mvglasow> I admire your ambition :-) consider this an intermediate step, it shouldn't break anything
[18:32:24] <jkoan> thx, i also like working with you :-) good to have you around our project
[18:33:53] <jkoan> probably while we are at the build side, i can also consider to move the android build to github actions
[18:35:15] <mvglasow> as I understand, we could have one alongside the other, right?
[18:36:40] <mvglasow> being a cautious person, I would suggest setting up Github actions first, once that works, we can phase out CircleCI (ohhh, I smell feature creep :-))
[18:38:58] <jkoan> yes, thats right, we only need to consider that we man only upload to google play from one ci, but i can handle thy with one enviroment variable
[18:39:29] <jkoan> afk ~20min
[19:30:47] *** Joins: owler (~owlman@61-68-86-34.tpgi.com.au)
[19:36:32] *** Quits: owlman (~owlman@61-68-86-34.tpgi.com.au) (*.net *.split)
[19:38:14] *** Quits: bzed (~bzed@shell.bzed.at) (Remote host closed the connection)
[19:41:27] *** Joins: bzed (~bzed@shell.bzed.at)
[21:36:02] <jkoan> mvglasow: from the log https://circleci.com/api/v1.1/project/github/navit-gps/navit/22763/output/105/0?file=true&allocation-id=6030067ac780e31b0c74ffb5-0-build%2F1B3E4957 i see that the apk-filename is now https://circleci.com/api/v1.1/project/github/navit-gps/navit/22763/output/105/0?file=true&allocation-id=6030067ac780e31b0c74ffb5-0-build%2F1B3E4957 code-release.apk instead of android-release.apk. Any clue why?
[22:00:01] <mvglasow> No idea, what branch/commit is that for, and is that the regular Android build or the F-Droid one?
[22:02:10] <jkoan> its the master build on circleci so regular
[22:02:26] <jkoan> but now i know, the upper directory is called code
[22:03:06] <mvglasow> ah, was that following the build.gradle consolidation?
[22:03:15] <jkoan> yep
[22:03:42] <mvglasow> we're building from a different dir, that might be the reason
[22:03:53] <jkoan> exactly
[22:04:03] <jkoan> will fix this tomorrow
[22:04:43] <jkoan> probably then we can also add to upload the apk with the git sha