GitHub has no configure file. Only configure.am.
No idea, how to handle it.
Memcached use Autotools to build source, as you got configure.ac and Makefile.am, follow these steps to build the source:
./autogen.sh
./configure
make
The binary is generated now, find the location by running find * -name memcached.
Related
I am using the z3prover first time, after reading most of related answers, I have noticed that I need to try: sudo make install .How could I skip the link z3 in /usr/bin and /usr/lib to use z3++.h in my own c++ project. (bcs I have noticed not everyone has the sudoer, I hope my code would goes well without sudoer.
You do need to compile the z3 source code if you want to be able to use it in your C/C++ projects. Compiling it will give you the library to link against. If you just download the source code, you can find the headers but you cannot link and hence cannot create your own executables.
But doing so does not require sudo access at all. The proper way to do so is actually explained in the https://github.com/Z3Prover/z3 page, right in the README. Roughly, they go like this:
python scripts/mk_make.py --prefix=/home/leo
cd build
make
make install
Note in the prefix parameter of the first line you tell z3 where to install everything. Change that path to a place where you have write-access. This way you do not need sudo access.
In order to compile your project successfully, you need to tell your compiler where to look for dynamic libraries and header files. Ask separately if you run into issues.
If you use GCC as the compiler you should add -I option for your project as follows :
g++ -Iz3_path/include -Lz3_path/lib -lz3
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
In attempting to install the latest ImageMagick (and devel) RPM from http://www.imagemagick.org/download/linux/CentOS/x86_64/ I receive this message
ImageMagick-libs = 6.8.5-8 is needed by ImageMagick-devel-6.8.5-8.x86_64
Confusingly, there is no ImageMagick-libs RPM listed, and searching has yet to yield a solution. Is there a way around this existential dependency?
Neither I nor Google know where ImageMagick-libs lives nor what it contains, but for posterity this gets things up and running on CentOS 5.8 (the distribution listed on imagemagick.org):
>: rpm -Uvh --nodeps ImageMagick-6.8.5-8.x86_64.rpm ImageMagick-devel-6.8.5-8.x86_64.rpm
>: ln -s /usr/include/ImageMagick-6 /usr/include/ImageMagick
The symbolic link was necessary for software relying on ImageMagick header files.
If someone were to stumble upon this, the ImageMagick-libs RPM are now downloadable from the link in the question.
I ran into the same thing when building the RPMs myself.
line 66 of the SRPM's included ImageMagick spec file includes:
Requires: %{name}-libs = %{version}-%{release}
I just commented out that line and the build completes; the resultant RPM satisfies the requirement cleaner. In sum, I believe it a bug in the SPEC file bundled in the SRPM. It isn't necessary for functionality even when building against php magickwand and similar finicky tools that require headers from ImageMagick.
Im using gnat4.6 on Ubuntu installed using apt-get. I need to know where to install downloaded libraries like APQ. What should I set my ADA_INCLUDE_PATH and ADA_OBJECTS_PATH to?
The beauty of Ada support in Debian (on which Ubuntu is based) is that you don't need to mess with ADA_INCLUDE_PATH and friends; supported libraries are installed where the GNAT Project Manager expects to find them. Say gnatls -v to see the default values.
To use the system as intended, you will find it much simpler to use the GNAT Project Manager; you'd say, in your my_project.gpr file,
with "apq";
project My_Project is
...
and build with
$ gnatmake -P my_project
There's online documentation for GPR, but I wouldn't call it particularly user-friendly. There's a set of Youtube videos (I haven't looked at them in any detail; their stated interest is large systems, but hang in there).
I use gnatmake to build; how do I cite my build paths in a correct way?
The relevant options are shown in 6.2 Switches for gnatmake: Source and library search path switches.
Addendum: The development package is libapq3.2.0-dev.
The manual is in /usr/share/doc/libapq3.2.0-dev/manual.pdf.gz
An example and corresponding .gpr file are in /usr/share/doc/libapq3.2.0-dev/examples. As #Simon suggested, the .gpr file begins:
with "apq.gpr";
project APQ.Samples is
The Ada include files are in /usr/share/ada/adainclude/apq.
The libraries are in /usr/lib.
$ dpkg -L libapq3.2.0-dev
/.
/usr
/usr/share
/usr/share/ada
/usr/share/ada/adainclude
/usr/share/ada/adainclude/apq
/usr/share/ada/adainclude/apq/apq_helper.ads
/usr/share/ada/adainclude/apq/apq_helper.adb
/usr/share/ada/adainclude/apq/apq.adb
/usr/share/ada/adainclude/apq/apq.ads
/usr/share/ada/adainclude/apq.gpr
/usr/share/doc
/usr/share/doc/libapq3.2.0-dev
/usr/share/doc/libapq3.2.0-dev/copyright
/usr/share/doc/libapq3.2.0-dev/manual.pdf.gz
/usr/share/doc/libapq3.2.0-dev/examples
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.adb
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.ads
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.gpr
/usr/lib
/usr/lib/libapq.a
/usr/lib/ada
/usr/lib/ada/adalib
/usr/lib/ada/adalib/apq
/usr/lib/ada/adalib/apq/apq_helper.ali
/usr/lib/ada/adalib/apq/apq.ali
/usr/share/doc/libapq3.2.0-dev/changelog.Debian.gz
/usr/lib/libapq.so
I've been frustrated by the the CMake-CPack for almost one week.
The bad thing is the CMake-CPack online documentation does not document this part well.
After googling, I found this variables to use:
CPACK_PACKAGING_PREFIX # NOT documented
CMAKE_INSTALL_PREFIX # Documented, but the behavior seems weird
CPACK_INSTALL_PREFIX # NOT documented
CPACK_PACKAGE_INSTALL_DIRECTORY # Documented, but this variable does NOT work as the online document described
CPACK_PACKAGING_INSTALL_PREFIX # NOT documented
What I am trying to do is: package a Debian package using fakeroot make package, when the package is installed by sudo dpkg -i MyProgramPackageName, install it to /usr/local, with a subdirectory MyProgramPackageName. That is, all files should be installed under /usr/local/MyProgramPackageName-V.1.2.3.
I've been trying (CMake 2.8.3 and CMake 2.8.5) to tune these variables. I tried so many combinations, but failed.
The only way succeeded is:
Set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/MyProgramPackageName-V.1.2.3)
But this variable is NOT even documented, and the behavior cannot be guaranteed. If you are confused with my question, please advise me when to use CPACK_PACKAGE_INSTALL_DIRECTORY? because the documentation description about this variable is really attractive, and it is really what I want, but I just could not make it working.
Please advise me.
Peter
I didn't find any documentation to support this, but I did find some bug reports and email archives that seem to suggest that the following is what you should be doing:
set(CPACK_SET_DESTDIR true)
set(CPACK_INSTALL_PREFIX /opt/MySuperAwesomePrefix-v.1.2.3)
If CPACK_INSTALL_PREFIX is not set, it will default to CMAKE_INSTALL_PREFIX. Now relative paths from install(... DESTINATION dest) will end up as CPACK_INSTALL_PREFIX/dest inside your package file. This worked when I tried to generate a deb file.
The paths used by the CPACK are taken from the INSTALL directives in your CMakeLists.txt files. This allows the result package to mirror what a 'make install' would do. This keeps the CPACK configuration to a minimum.
So, from an example CMakeLists.txt file:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin)
This will install to /usr/bin or /usr/local/bin. If you wanted to place it in a subdirectory you could do it here:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin/myappdir)
Or entirely different directory:
INSTALL(TARGETS ${APPLICATION} DESTINATION /opt/foo/bar)