-
Notifications
You must be signed in to change notification settings - Fork 179
downloads require running autoreconf -i and autoconf undocumented #96
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
Comments
Putting
from the root folder of the project. That said, I just tried master on a recent Ubuntu and I was getting some warnings so it doesn't appear to be working properly at the moment. This is something I need to start checking with more diligence on release tags. @qdii @magicant @LocutusOfBorg @bittwiddler1 any of you have a moment to look at this? I won't get to it for a few days, and you have all contributed at one time or another to the autoconf support. |
I'm ok with having to do something before the configure if neccessarily but the README starts with Thanks |
I'm unclear on the particulars of your previous comment. ./configure is not mentioned in the README; only CMake (the primary supported build system) is mentioned there. |
Hmm, I downloaded unittest-cpp-1.5.0 and the INSTALL file states: Briefly, the shell commands `./configure; make; make install' should Am I accidently in the wrong universe? Should switch to 1.51? |
Ah, I was looking at the README. Now that I see what you're saying, I'd say the INSTALL file is out of date. If you must autotools, then I'm afraid things appear to be broken at the moment; I'd be happy to see a PR from you or anyone else on this as I doubt I'll have the cycles for a few days. If you can use CMake, then you can should be able to install using the instruction me here: https://github.com/unittest-cpp/unittest-cpp/wiki/Building-Using-CMake |
Ahh, running autoreconf on my Apple worked fine but it looks like my autoconf on my linux system is out of date hence could not generate ./configure. I'll try the cmake. I hate cmake and wish you had stuck with autotools but ..... |
I don't particularly love CMake either, but I am not interested in reopening that conversation at this time. As previously stated, I'll happily accept PRs on the autotools support files -- so I wouldn't say the project has abandoned it. Sorry for the inconvenience. |
I'm trying the commit 5b34768 on Fedora 23 with Autoconf 2.69, and don't find any particular issue about autoconf. The commands
just work for me. @pjohnmeyer Are you running |
@magicant I was, switched to your method as above [Ubuntu 15 and autoconf 2.69] and got some errors. Realized that I didn't have @BarrySmith, can you see if it works this way for you? If so, this is just a documentation problem. |
Doing this: |
From what I've experienced with GNU auto tool packages, they usually ship with a pregenerated configure shell script... If the makefiles support it, (and if I understand correctly) running |
Im preoccupied with work and family but I might be able to take a look tomorrow |
This works fine for my on my Apple Mac (latest Xcode) but on linux-Ubuntu_12.04-x86_64 with autoconf-2.69 automake-1.15 libtool-2.4.6/bin I get $ autoreconf --force --install -v But if I run libtoolize first then run autoreconf --force --install it works! I have no idea why.
|
@pjohnmeyer unfortunately I'm a huge CMake fan, and I really don't understand how autotools works, IIRC I just did a fix in a pkgconfig file, but I try to stay away from autotools issues whenever possible. So for me +1 for CMake switch :) |
@LocutusOfBorg AFAIK, unittest-cpp is already primarily using CMake for builds, so there's no need! However, I was under the impression the GNU Autotools files were here for those who don't have CMake installed on their system. I know CMake is an awesome tool, but it's also much more dependency-heavy than the GNU Tools, which mostly depend on text-processing programs. Here's a high-level overview of how the auto tools are supposed to work:
If you really need good |
@pjohnmeyer It actually depends on who's compiling the package. For the purposes of avoiding clutter in your source control and the source tree, you don't generally check in the
From where I stand, @BarrySmith's issue is mostly an issue of distribution practices and documentation.
If it were me, I'd just make sure the release tarball has a ./configure at the root, and/or document that people building from github need have the autotools on their systems in order to generate (See also: https://www.gnu.org/software/automake/manual/html_node/Preparing-Distributions.html) |
Thanks for all the input, everybody, I'm the first to admit I'm a little light on autotools knowledge. @BarrySmith : The To this point, I've only been tagging code -- I haven't been creating true releases through GitHub. To that extent, 1.5.* releases have been source distributions only. If preparing an autotools distribution would make life significantly better for the Linux dev community, I'd be happy to spend a little more time on it. The main effort would be in writing a release script, which I need to do anyway. I haven't decided precisely how I want to solve this "problem" though; so I'm gonna put a few more days of thought into it. |
So, I've spent some more significant time with the autotools files tonight because on #95 I had previously neglected to updated the I would personally prefer to only support CMake, but I appreciate the use case for autoconf. I'm going to experiment a bit more before addressing this thoroughly. |
As you all may have noticed I went ahead and tagged v1.6.0 tonight without having resolved this. However, I intend to address these issues in March and will most likely include, with that, uploading distributions for older tags as well, if it doesn't prove to be too difficult. |
When I release 2.0, as with 1.6.1, the ./configure file will be included in the tarball. I am also adding a small note to the top of the install file to indicate that if you're building from source you'll need to run autoreconf. I won't be going back and fixing old download packages. |
I may have missed something but if one downloads either with git or the "release" tarballs configure is not available so one must run
autoreconf -i
autoconf
before running configure. This seems does not seem to be documented anywhere.
Couldn't you provide tarballs with the configure already there?
The text was updated successfully, but these errors were encountered: