Created attachment 104588 [details] patch allowing code and docbooks to build on Mac I finally got around to building Kexi 3.0.1 on Mac and ran into a number of building issues: - a missing find_package of KDocTools and missing argument in kdoctools_create_handbook for the English docbook - Q_OS_MAC should be Q_OS_MACOS - the moc compiler doesn't respect conditional code or not reliably so, and slot functions should thus always all be present. If they have to be conditional, keep the function declaration outside the #ifdef and the actual payload inside. I'm attaching the patch with which I finally could build the code. Kexi seems to run OK with it (but I'm hardly an expert).
Thanks so much René. The changes will be applied and 3.0 merged into master. So if Kexi builds I am assuming the kdb/kreport/kproperty libs were also built by you. If you have any fixes for them we would apply them too.
Git commit 8b4116cb27268cb7c95ee504370d931ddf43d31f by Jaroslaw Staniek. Committed on 15/03/2017 at 23:16. Pushed by staniek into branch '3.0'. Q_OS_MAC -> Q_OS_MACOS M +3 -3 src/tools/KDbUtils.cpp M +1 -1 src/tools/KDbUtils_p.h https://commits.kde.org/kdb/8b4116cb27268cb7c95ee504370d931ddf43d31f
Git commit 07fddc66d47f45caf7a56632ae7138046ed9fff5 by Jaroslaw Staniek, on behalf of René J.V. Bertin. Committed on 15/03/2017 at 23:47. Pushed by staniek into branch '3.0'. Fix build for macOS: Q_OS_MAC -> Q_OS_MACOS M +1 -1 src/kexiutils/completer/KexiCompleter.cpp M +1 -1 src/main/KexiBugReportDialog.cpp M +1 -1 src/main/KexiMainWindow.cpp M +1 -1 src/main/KexiMenuWidget.cpp M +1 -1 src/main/KexiUserFeedbackAgent.cpp M +1 -1 src/main/startup/KexiWelcomeStatusBar.cpp https://commits.kde.org/kexi/07fddc66d47f45caf7a56632ae7138046ed9fff5
Git commit ea10b879e4cf712bbfc2308f85b72f6f4b301172 by Jaroslaw Staniek, on behalf of René J.V. Bertin. Committed on 15/03/2017 at 23:48. Pushed by staniek into branch '3.0'. Fix build for macOS: keep empty definitions of slots M +17 -3 src/main/startup/KexiWelcomeStatusBar.cpp https://commits.kde.org/kexi/ea10b879e4cf712bbfc2308f85b72f6f4b301172
All except for the doc-related changes are in 3.0 and master now. The code in doc/en is generated by a release script so we would need to handle it differently.
Also fixed Q_OS_MAC in 2 files of kdb.git. Would be great if you test 3.0 branches of kexi and kexi libs. And master branches. Thanks.
(In reply to Jarosław Staniek from comment #1) > So if Kexi builds I am assuming the kdb/kreport/kproperty libs were also > built by you. If you have any fixes for them we would apply them too. You already found the Q_OS_MAC->OS changes; I also think the sqlite dump tool should be built as a regular executable that can be put somewhere on the path: ========== diff --git a/src/drivers/sqlite/dump/CMakeLists.txt b/src/drivers/sqlite/dump/CMakeLists.txt index af134d8..cfffb5c 100644 --- a/src/drivers/sqlite/dump/CMakeLists.txt +++ b/src/drivers/sqlite/dump/CMakeLists.txt @@ -1,6 +1,9 @@ +include(ECMMarkNonGuiExecutable) + set(kdb_sqlite_dump_tool_SRCS main.cpp shell.c README) add_executable(${KDB_SQLITE_DUMP_TOOL} ${kdb_sqlite_dump_tool_SRCS}) +ecm_mark_nongui_executable(${KDB_SQLITE_DUMP_TOOL}) target_link_libraries(${KDB_SQLITE_DUMP_TOOL} PRIVATE ==========
(In reply to Jarosław Staniek from comment #6) > Would be great if you test 3.0 branches of kexi and kexi libs. And master > branches. Thanks. Anything else? :D I would if I were actually using Kexi one way or another. I just don't have any personal use for it, and quite a few other ports that I have to maintain and that keep me more than busy enough with their short release cycle. I'm not saying no, just that it's not very likely I'll get around to it in time.
> sqlite dump tool OK, good, TODO soon. > Anything else? Creating an empty Kexi project for 1. SQLite format, 2. MySQL format, 3. PostgreSQL format. This would test if the plugins are built, properly placed (I am just not sure here) and actually work at runtime (has all dependencies). We have now universal Linux binaries available to compare how it should work: https://community.kde.org/Kexi/Snapshots - the binary has 1. and 2. working and 3. almost working (a few dependencies missing) > I would if I were actually using Kexi one way or another. I fully understand. You brought more than I'd expect. A number of Mac-using devs offered joining Kexi and this not materialized or lasted long, while you acted quickly and with a good result. I have one question now, may I ask you e.g. before releases, especially before the 3.1.0 to check if Kexi builds and just runs? To facilitate the "runs" test I'd think about an app's self-test that's shipped even if tests are not built. I would not ask for such things but I see no continuous integration support for macOS for now. If you see any chance for it or any remote access to a macOS machine for such tests I'd be grateful. Thanks!
Reopening to fix the sqlitedump...
That "anything else" was actually a joke... Would it be possible to put some sample projects online, or is it a better (or sufficient) test to create new projects? As to plugin placement: I build and install following the usual layout, not as standalone app bundles. This aspect should be fine if the build scripts work with a non-standard install prefix. I planned to do the pre-release test as you suggest, but simply didn't get around to it with the other things going on here. Feel free to prod me before the next (major) release so I can try to give an estimate of how much time I'd need. There *is* a KDE Mac builder machine and AFAIK it runs a CI. There have been some issues with it in the past so I don't know how operational it is at the moment.
In src/examples you can see a Simple_Database.kexi file that you shall be able to open with Kexi. As for server Kexi projects there are no such test servers online (mysql, postgrsql) yet but we will want to have it too. So to test the server projects support creating an empty one would be the current approach. Of you ever have time, compiling with -DBUILD_TESTING=ON and running `ctest` for all the 4 repos would be very useful test too on macOS. Sqlite support is only tested there (so far) but it's already better suite of tests than just running manually.
The simple_Database example opens just fine (it's MySql, right?), and creating a new database also works. I don't see how to create one that's not SQlite though.
Created attachment 104600 [details] attachment-24044-0.html Simple_database is a sqlite file On Thu, 16 Mar 2017, 13:42 RJVB, <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=377662 > > --- Comment #13 from RJVB <rjvbertin@gmail.com> --- > The simple_Database example opens just fine (it's MySql, right?), and > creating > a new database also works. I don't see how to create one that's not SQlite > though. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are watching someone on the CC list of the bug.
Good. It's SQlite. .kexi files are SQLite3 files. To create a MySQL file: - start Kexi - Kexi->New command, select 'Blank' - Click the Server button - Click Add.. - If you have a local MySQL server running, keep the default options, just in the Authentication box enter username and password (you can save password if you want) - recommended: click 'Test Connection'; does it work for you? - Click Add, dialog closes - Click Next (on the right-top) - You may be asked to enter password if it was not saved; click Next - Connecting happens now - Enter Project caption; database name will be created based on that - Click Create. Now you should have an empty project fully stored on the server. You can create tables/queries/etc. there.
BTW, The same recipe would be for PostgreSQL projects.
Hmmm, except that the only mysql server I have running is the one for Akonadi. I'm not sure I would dare using that one...
Is this a regular server or mysql-embedded? If it's regular and you have credentials allowing you to connect I do not see any risk - Kexi creates separate database on that server (and actually a tiny one).
Otherwise there's a DMG archive at https://dev.mysql.com/downloads/mysql/ and actually you can set it up so it won't be started automatically after booting so you don't have much overhead.
> That "anything else" was actually a joke... By testing in this thread I mean checking is this stack actually builds :) Running ctest would be a nice extra.
Git commit 35c31ea9b7a856593204c6ed4a6db7cfc4a1867a by Jaroslaw Staniek, on behalf of René J.V. Bertin. Committed on 16/03/2017 at 20:59. Pushed by staniek into branch '3.0'. Mark the KDB_SQLITE_DUMP_TOOL as non-gui (useful for Windows and macOS) GIT_SILENT M +3 -0 src/drivers/sqlite/dump/CMakeLists.txt https://commits.kde.org/kdb/35c31ea9b7a856593204c6ed4a6db7cfc4a1867a
OK I think can we close. If there's anything new feel free to report, thanks!