Clean up automake buildsystem

[ndim]

This is to track my efforts at cleaning up the build system and discussing them. So far, I have about 40 git commits which I need to reorder in a logical way.

Some questions to come later, this is not my full time paid work project after all.

[oneeyeman1]

Thank you. I appreciate you doing it and sorry for not be able to pay.

Just to clarify some stuff - I started this project with MSVC, Anjuta and code in 2014/2015 timeframe. At the time Anjuta was the "only feasible" solution to write an applicatuion for GTK that supported creating a project for wxWidgets. (Code::Blocks/CodeLite aside). And Anjuta used (and still uses) autotools and friends, but it didn't see an updates for a long time.

I tried to look at Builder, but that IDE - 1. does not support wxWidgets (which is a big issue that project) and 2. can't create a library (so/a) project. So this can not be a good IDE for me (and anybody else for that matter, because of 2). ;-)

I hope that clears up some (future) questions you might have.

[ndim]

Some source files use DOS style CRLF line endings, some use Unix style LF line endings, and some use mixed line endings. What is the goal here?

There appear to be a number of (copies of) external software sources inside the source tree, and I cannot see why, so I removed them to have less clutter in the way and to see more clearly what code parts actually matter. They appear to be (mostly to completely) unused anyway.

• /mysql-server/ (git submodule)
• /mysql-connector/ (local copy)
• /libpg/ (local copy)

Or do you actually need those?

libmysql/database_mysql.cpp needed a lot of casts to even compile at all, but I have no idea whether they make sense at all. In any case, the repetitiveness of the code and the indentation depth (code starting in column 90+) indicate something is very wrong with the code. I am not here for the code, I am here for the build system, so I just forced it to compile whether the code actually makes sense or not.

All those libraries in the subdirs... are those intended as actual libraries which are to be installed alongside the dbhandler executable? Or are they (or some?) supposed to be just libtool convenience libraries? And why is there still a non-libtool library? I presume an oversight?

You are making intensive use of recursive make. Is that on purpose, or can we go for completely parallel make (except for the po/ stuff)? Completely parallel gives about a 50% build time speedup on my 6p12t machine, and it solves some dependency issues.

There appears to be some work to be done regarding intltool, but that is a part which I am not familiar with yet. In any case, the autogen.sh script appears to be unnecessary, and autoreconf -vis or autoreconf -vif can replace autogen.sh just fine.

I have not touched any anjuta/xcode/vscode project files.

[oneeyeman1]

Hi,

Some source files use DOS style CRLF line endings, some use Unix style LF line endings, and some use mixed line endings. What is the goal here?

Interesting. I don't have any issues building anything retrieving the code on all 3 major platforms - Windows, *nix and OSX. I never tired any real UNIX machine just Linux.

However, my main platform for Development is Windows.

So for now, I'd say - leave it alone.

There appear to be a number of (copies of) external software sources inside the source tree, and I cannot see why, so I removed them to have less clutter in the way and to see more clearly what code parts actually matter. They appear to be (mostly to completely) unused anyway.

• /mysql-server/ (git submodule)
• /mysql-connector/ (local copy)
• /libpg/ (local copy)

Or do you actually need those?

The intention is to have a prebuilt binaries for Windows/OSX. While on Linux those packages could be installed from the official repository on Windows/OSX there is no such thing. So in order to test functionality under PostgreSQL/mySQL I built the client libraries under those platforms and push them into the tree. With mySQL its kind of weird. They used to call the library mySQL-Connector-C with the good documentation on how to build and use it. And now they switched to the new way of building which is not documented at all. That's why I have 2 copies for the mySQL. (Under Linux I will use new version and old version will be used under Windows/OSX still).

libmysql/database_mysql.cpp needed a lot of casts to even compile at all, but I have no idea whether they make sense at all. In any case, the repetitiveness of the code and the indentation depth (code starting in column 90+) indicate something is very wrong with the code. I am not here for the code, I am here for the build system, so I just forced it to compile whether the code actually makes sense or not.

Yes, just make it compile and move on. ;-) But I am surprised it didn't compile for you. Out of curiosity - what compiler/OS did you use? It is quite possible that the errors are due to me trying to play nice with the mySQL client library switching.

All those libraries in the subdirs... are those intended as actual libraries which are to be installed alongside the dbhandler executable? Or are they (or some?) supposed to be just libtool convenience libraries? And why is there still a non-libtool library? I presume an oversight?

All of them will be installed. They are all part of the software.

About the static library "dbinterface". This library contains one exported class (interface) that all those database_*.cpp classes are children of. At the time it just seemed easier to make it this way.

You are making intensive use of recursive make. Is that on purpose, or can we go for completely parallel make (except for the po/ stuff)? Completely parallel gives about a 50% build time speedup on my 6p12t machine, and it solves some dependency issues.

Not completely sure what you mean here. As long as build dependencies will be satisfied, we can make improvements to this.

There appears to be some work to be done regarding intltool, but that is a part which I am not familiar with yet. In any case, the autogen.sh script appears to be unnecessary, and autoreconf -vis or autoreconf -vif can replace autogen.sh just fine.

That is probably an Anjuta file for when the project was just created first time on Linux and it had to create all necessary files for the build to succeed. I'm not sure though.

I have not touched any anjuta/xcode/vscode project files.

OK.

Let me know if something is not clear in my responses.

[ndim]

So I was wrong here: My editor (emacs) shows files with all-LF endings and files with all-CRLF endings in the same way as a standard text file. It is only text files with mixed line endings.

It was the CRLF line ending files where a few some lines had been added with LF line endings which showed up weird in my editor (with every CR shown as ^M).

Some source files use DOS style CRLF line endings, some use Unix style LF line endings, and some use mixed line endings. What is the goal here?

Interesting. I don't have any issues building anything retrieving the code on all 3 major platforms - Windows, *nix and OSX. I never tired any real UNIX machine just Linux.

However, my main platform for Development is Windows.

So for now, I'd say - leave it alone.

git allows adding a .gitattributes file to have "git clone" check out text files in native line endings, whatever those line endings might be. But you are right, I will leave this be.

[ndim]

All those libraries in the subdirs... are those intended as actual libraries which are to be installed alongside the dbhandler executable? Or are they (or some?) supposed to be just libtool convenience libraries? And why is there still a non-libtool library? I presume an oversight?

All of them will be installed. They are all part of the software.

The question is whether those 13 libraries need to be installed as separate library files with the dbhandler executable being dynamically linked to all twelve of them, or whether the dbhandler executable just containing their code is sufficient.

If those 13 libraries are actually supposed to be installed, their very generic names should probably be changed to something which indicates they are part of dbhandler (libpostgres, libmysql_lib, libodbc_lib, libdialogs, well... almost all of them, really):

current name           proposed name #1           proposed name #2

libdbloader            libdbh_dbloader            libdbhandler_dbloader
libdbwindow            libdbh_dbwindow            libdbhandler_dbwindow
libdialogs             libdbh_dialogs             libdbhandler_dialogs
libfieldswindow        libdbh_fieldswindow        libdbhandler_fieldswindow
libmysql_lib           libdbh_mysql_lib           libdbhandler_mysql_lib
libodbc_lib            libdbh_odbc_lib            libdbhandler_odbc_lib
libpostgres            libdbh_postgres            libdbhandler_postgres
libpropertieshandlers  libdbh_propertieshandlers  libdbhandler_propertieshandlers
libpropertypages       libdbh_propertypages       libdbhandler_propertypages
libshapeframework      libdbh_shapeframework      libdbhandler_shapeframework
libsqlite_lib          libdbh_sqlite_lib          libdbhandler_sqlite_lib
libtableedit           libdbh_tableedit           libdbhandler_tableedit
libtablewindow         libdbh_tablewindow         libdbhandler_tablewindow

About the static library "dbinterface". This library contains one exported class (interface) that all those database_*.cpp classes are children of. At the time it just seemed easier to make it this way.

So a libtool convenience library is the way to go for libdbinterface, then.

[oneeyeman1]

OK, in terms of name:

libdbhandler_sqlite, _odbc, _postgres and _mysql should be fine to indicate that it is part of dbhandler and don't clash with native client libs name. These 5 libraries are like plugins to the actual DBMS - one can take them, place to another software and (knowing the interface API) use it to connect and perform the queries. The actual connection is done thru the libdbloader (see below) The rest - I don't care. We can probably use #1 to type less. ;-)

About the static library "dbinterface". This library contains one exported class (interface) that all those database_*.cpp classes are children of. At the time it just seemed easier to make it this way.

So a libtool convenience library is the way to go for libdbinterface, then.

I don't know how well versed you are with C++, so didn't want to give you too much details Basically dbinterface has many pure virtual functions with the actual implementations inside database*.cpp classes. The program links to the dbinterface and then the linker loads an appropriate library during the connect call from the libdbloader.

As I said - it looked easier to make it statically linked and use dynamic linking for the actual implementation. But since *nix prefer so to a library, you solution might work.

Thank you.

[ndim]

A libtool convenience library is a a build time thing. You add objects files to it, and can link it to proper libtool libraries and to programs, but it is not installed.

It basically behaves like a static library used only during the build, but where libtool takes care of compiling and linking with the proper compiler and linker flags (no need to know about -fPIC or other compiler specific flags).

[ndim]

I just ran anjuta with dbhandler and found it lacking in its Automake plugin. Is seamless integration into anjuta important for you? That could mean sacrificing some convenience or some compile speed.

[oneeyeman1]

Anjuta was important when I started the project. I was not sure how to handle the so/a build/project stuff and create dependencies between the subprojects so that one will be built after another.

But at this point - no. I can do that manually.

I can still run Anjuta from time to time, but if I have the good build system in place - I will just grab the updated code and build.

And if I need the additional library to be created - I will follow with what Anjuta and you did and make it work.

I do know how to read - just not Autotools (yet) ;-)

Thank you.