Bear with me, this one's not very easy to explain...
I'm trying to configure, make and make install Xfce into my buildroot build directory. When configuring I'm using
--prefix=/home/me/somefolder/mybuild/output/target
so that it builds to the right folder, however when it's compressed and run I get errors from various config files where it's looking for files in
/home/me/somefolder/mybuild/output/target
(which of course doesn't exist.)
How do I set what folder to build into, yet set a different root directory for the config files to use?
Do configure --help and see what other options are available.
It is very common to provide different options to override different locations. By standard, --prefix overrides all of them, so you need to override config location after specifying the prefix. This course of actions usually works for every automake-based project.
The worse case scenario is when you need to modify the configure script, or even worse, generated makefiles and config.h headers. But yeah, for Xfce you can try something like this:
./configure --prefix=/home/me/somefolder/mybuild/output/target --sysconfdir=/etc
I believe that should do it.
In my situation, --prefix= failed to update the path correctly under some warnings or failures. please see the below link for the answer.
https://stackoverflow.com/a/50208379/1283198
Related
Steps:
Installed coverity
Configured compiler
cov-configure --javascript
cov-configure --cs
I am stuck at the build step of cov-build. Yarn is used to run and configure the service. But I am not sure what coverity wants here.
I tried a couple of npm run commands, every time end up getting this:
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
I also tried different compilers, but no luck.
What should be done in this case?
You need to do a file system capture for Javascript files. You can accomplish this by running cov-build with the --no-command flag.
cov-build --dir CoverityIntermedediateDir --no-command --fs-capture-list list.txt
Lets break down these commands:
--dir: intermediate directory to store the emitted results (used for cov-analyze later).
--no-command: Do not run a build command and to look for certain file types
--fs-capture-list: Use the file that is provided to specify which files to look at and possibly emit to the intermediate directory.
A recommended way to generate the list.txt file is to grab it from your source control. If using git run:
git ls-files > list.txt
I want to also point out that if you don't have a convenient way to get a file listing in order to use the --fs-capture-list command you can use --fs-capture-search command and pair that with a filter to exclude the node_modules directory.
The coverity forums have some useful questions and answers:
Node.js File system capture
Really, the best place to look is at the documentation. There are several examples of what you want to do in their guides.
My main goal is that I want to understand how parameters works in ./configure. So, I decided to install ncurses and vim in $HOME/local/, so, as to not affect my system.
while configuring vim, I looked into --with-local-dir and includedir. I want to know what is the difference between them.
When I looked into vim-git-INSTALL-script, it said:
Unix: LOCAL HEADERS AND LIBRARIES NOT IN /usr/local
Sometimes it is necessary to search different path than /usr/local for locally
installed headers (/usr/local/include) and libraries (/usr/local/lib).
To search /stranger/include and /stranger/lib for locally installed
headers and libraries, use:
./configure --with-local-dir=/stranger
I thought that was the purpose of includedir. I would appreciate if someone can tell me where I went wrong. Thank you!
Conventionally (and per documentation), includedir is used for the directory where the current program would install header files. That's not the same as the places where the configure script might have to tell the compiler to find the header files needed to compile the program.
I need to build libpng, but without #define PNG_READ_eXIf_SUPPORTED in pnglibconf.h
I've read comments from pnglibconf.dfa, and here are some ways of disabling features, however I didn't manage to make what I want using them.
The problem is in that, build process is performed on build server, so I can't change any files inside of libpng submodule. Here is how server works:
Download clone sources from git
Generate makefile by running cmake ..
Run make command.
Thus I have libnpg, but with included PNG_READ_eXIf_SUPPORTED option.
Libpng is a submodule of my project, so it checked out by build server automatically so I can't change pnglibconf manually.
As it said in pnglibconf.dfa file:
There are three ways of disabling features, in no particular order:
1) Create 'pngusr.h', enter the required private build information
detailed below and #define PNG_NO_<option> for each option you
don't want in that file in that file. You can also turn on options
using PNG_<option>_SUPPORTED. When you have finished rerun
configure and rebuild pnglibconf.h file with -DPNG_USER_CONFIG:
make clean
CPPFLAGS='-DPNG_USER_CONFIG' ./configure
make pnglibconf.h
pngusr.h is only used during the creation of pnglibconf.h, but it
is safer to ensure that -DPNG_USER_CONFIG is specified throughout
the build by changing the CPPFLAGS passed to the initial ./configure
I tried to do what is written here. I run cmake .. -DCMAKE_C_FLAGS="-DPNG_USER_CONFIG -I/home/me/dev/include" where /home/me/dev/include - is a path to pngusr.h file
Then I run make command. However, PNG_READ_eXIf_SUPPORTED is still present in generated (by make command pnglibconf.h file).
So my main question is how to make libpng without PNG_READ_eXIf_SUPPORTED option?
It remains unclear to me whether and to what extent the specific customization mechanism you are trying to use works in the version of libpng you are trying to use. But it looks like there's a simpler way. Just below the excerpt you posted, in the same file, is the second (of three) alternatives:
2) Add definitions of the settings you want to change to CPPFLAGS;
for example:
-DPNG_DEFAULT_READ_MACROS=0
(lightly formatted). I'm not in a good position to test that on the CMake-based build system, but it seems to work like a charm in the Autotools build system. From examining and comparing the two, I think it will work for CMake, too. In particular, you would want to run
cmake .. -DCMAKE_CPP_FLAGS="-DPNG_NO_READ_eXIf"
for your particular case.
Note, by the way, that the CPP (i.e. preprocessor) flags are the right place for an option such as you are specifying (for -DPNG_USR_CONFIG in your original attempt, too). In practice, though, they probably still work in the C compiler flags.
Currently, our installation instructions are:
autoreconf -fi
./configure
...
The autoreconf step generates the configure file from configure.ac and Makefile.in from Makefile.in. If one of the dependencies (say pkg-config) is not installed, both configure and autoreconf fail although the latter prints a cryptic error message.
When releasing source tarballs, should the configure script be supplied in the package or not? What other files need to be included if it has to be distributed? The directories build-aux and autom4te.cache and files aclocal.m4 were also created.
In an SCM repository, nothing autogenerated should be present (including configure — but developer opinions digress here). A tarball should contain the state after autoreconf -fi and/or autogen.sh (or whichever name you chose for it). Third, you could also use make dist, though it requires that all files that shall appear in the tarball are also listed in the Makefiles.
Your installation instructions are horribly broken. The user should not need to have the autotool chain installed to build your software. You must distribute the configure script in your tarball. Note that you should not include the configure script in your version control system. (You should not use your version control system as a distribution system.)
The configure script should be built by the maintainer and distributed in the tarball. End users should never have to touch it, and it is a good idea to ensure this via AM_MAINTAINER_MODE if you are using automake. If not, make sure your Makefile.in doesn't re-generate configure when running for end users.
Let automake generate a distribution for you if you want to know what else belongs there. The auxiliary directory build-aux and aclocal.m4 do, automat4e.cache doesn't.
I have seen that while installing new software in Linux, I always have to use first configure it.
But sometimes we need to pass various options like I did today to install lxml:
./configure --with-python=/opt/python27/bin/python
--prefix=/usr/local
--with-libxml-prefix=/usr/local
--with-libxml-include-prefix=/usr/local/include
--with-libxml-libs-prefix=/usr/local/lib
Now I want to know that how will the person know that what type of paramaters like --with-python can be used?
I mean:
Are those parameters same across all software packages or they vary software to software?
I even tried to read documentation as well, but no one mentions those parameters.
./configure --help
That will show you all options for that particular configure script.
Some are the same across all configure scripts produced by Autoconf (which is most of them, but not all); for instance --prefix is basically universal. Others are peculiar to the particular configure script.
./configure --help is always helpful. But I would say more about that in some packages not only is there a configure script in the top source directory but also the possible subdirectories. So, for knowing all possible parameters which can be passed to the configure script in the top source directory you should also have a look at the configure scripts in each possible subdirectory.
For example, in the top source directory of binutils-2.34 tarball there are --with-sysroot and --with-lib-path parameters with configure script. If you type ./configure --help under the top source directory, there are no document items for both of them because they are documented in the configure script under the subdirectory ld/. So you should type ./ld/configure --help.
I know about configure --help but the information provided is "light". The following GNU resources contain useful additional information:
Installation directory variables
Release process