Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build system issues #13

Open
codebrainz opened this issue Sep 19, 2015 · 5 comments
Open

Build system issues #13

codebrainz opened this issue Sep 19, 2015 · 5 comments

Comments

@codebrainz
Copy link

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.

@wolkykim
Copy link
Owner

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.

@wolkykim
Copy link
Owner

BTW, Thank you for your through comment.

@wolkykim
Copy link
Owner

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. :)

@codebrainz
Copy link
Author

Agreed.

Edit: I mixed comments on this and PR #14 so I updated the comments appropriately.

@codebrainz
Copy link
Author

I think this would be useful for the qlibc sub-build system:

http://www.gnu.org/software/automake/manual/html_node/Subpackages.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants