Build updates #71
Merged
Build updates #71
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added a macro file for finding jni information on systems and modified configure.in to take advantage of it. Also made a few other minor changes to the configure.in including a few more checks that were found by autoscan.
This was just a simple fix; the build does not like trying to call make with the parallel option (-j). Some users won't have autotools installed and sometimes it shouldn't be expected, e.g. calling rpmbuild with the spec file that is included requires that configure be present.
|
Pulled, thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The spec file did not work properly as it tried to run a parallel build. The configure.in needed to be updated because searching for the java programs and jni headers is made easier with the macro now committed to the config directory. Also included the autogen generated files so that rpmbuild would compile properly. This spec file now works on my CentOS 5 machine.
I agree with what everyone else is saying as far as the version tagging goes. I think that you just need to settle on a scheme for the version, e.g. jzmq-X.Y.Z = jzmq-0.1.0 or 1.0.0 or something. When building an rpm, it is very convenient to be able to call rpmbuild -ta jzmq-2.1.0.tar.gz versus what has to happen now when you click on download from github, which is:
tar -zxvf zeromq-jzmq-SHA1HASH.tar.gz
mv zeromq-jzmq-SHA1HASH.tar.gz jzmq-2.1.0
tar -czvf jzmq-2.1.0.tar.gz jzmq-2.1.0
rpmbuild -ta jzmq-2.1.0.tar.gz
I've placed 2.1.0 in the example above because this is the version that someone had committed in the spec file on 12/9/2010. When running rpmbuild, it expects the package name to be in the format package-name-X.Y.Z.tar.gz, so this is why I change the name to match what is in the spec file. This is just a few steps, but very cumbersome.
A tag should be made periodically, perhaps to coincide with zeromq releases, but with a different version, they are after all, two separate packages with different history, different release dates, etc... Before making the tag, run against all unit tests and always create a commit with an updated spec file version and updated configure.in version.
That is my .02 on the tagging bit.