Build system issues
codebrainz opened this issue · comments
The build system doesn't allow building from a directory other than the source tree. This is useful to avoid polluting the source directory with generated files and/or if the source directory is read-only. Autotools supports it out of the box if you don't hardcode paths like .. but instead use vars like $(top_srcdir) and $(top_builddir), depending on whether the files are generated or not.
Also, running a Bash script from the Make file makes it less portable and the script checking-out a Git submodule at compile-time makes people compiling source code not checked out from Git (ex. distribution tarball) required to install Git and have an active Internet connection. It might be better to add this to the "bootstrap" script.
Usually a bootstrap script (ex. autogen.sh) is used to setup the build system when checked out from Git. It generates the configure script (which shouldn't be checked into Git) so it's generated correctly for the Autotools versions being used, and using it for the Git submodule checkout seems somewhat more reasonable than doing it from Bash script at compile-time, as a convenience for developers.
The Make file also uses some GNU-Make-specific syntax and could be made much more short and portable if Automake was used. This might not be true, I'm not super familiar with the differences between various Make tools, but either way Automake allows you not to care.
For the qlibc dependency, you could use Autoconf to check whether it's already installed, and if not it could then use the embedded copy. This would buy karma points on distros where embedding libraries is frowned upon (Debian, Fedora, etc) if the library becomes packaged for them and still allows using the embedded copy as a fallback for where qlibc isn't already installed.
If you want (and I get some time) I could probably make a pull request to fix the build system issues.
You're all right but I think including the configure script is one of the tradition, the auto tool generates the configure script in pretty compatible way and users don't need to install autotools. I choose this way.
The reason it clearly include qlibc is to avoid any custom build options because qlibc could be compiled and installed with options that could break libasyncd. And both are written by me, so I can include it in libasyncd package, make it convenient. The network connectivity is required only once at the time you first compile them. qLibc is actively updating so I guess live binding would be easier for the maintenance for both users and developers.
BTW, Thank you for your through comment.
I appreciate your comment but if you're interested in then sending a pull request is the quick and practical way to participate. Talking with code is much faster. :)
Agreed.
Edit: I mixed comments on this and PR #14 so I updated the comments appropriately.
I think this would be useful for the qlibc sub-build system:
http://www.gnu.org/software/automake/manual/html_node/Subpackages.html