I have a project which has been checked out of Subversion and uses Scons for building. However, I have a library installed on my computer which Scons doesn't detect - it just says that the include file can't be found. Is there any way that I can direct Scons to the library location without altering the Sconscript file at all (because I don't want to have to deal with conflicts every time I update) - e.g. add a command line option that it will detect before searching for the include file? I can't even see all the available options because it doesn't respond to the --help option before it searches for the include files.
Okay, after some more googling, I found that there is a way to do it. gcc has a number of default directories that it searches (which I already knew - I just didn't know what they were defined as). The simplest way to do what I was after is to add the directories to these environment variables. The one that I needed was
$CPATH
This sets the path where gcc searches for its include files. Setting this to the directory I needed solved my problem.
you can set env["CPPPATH"], but I hope there's an easier way...
SCons has a concept of repositories - directories to look for source and target files. These can be specified on command line.
-Y REPOSITORY, --repository=REPOSITORY, --srcdir=REPOSITORY
Search REPOSITORY for source and target files.
To get to help of SCons itself, use -H option.
no you can't, unless the developer of the scons script explicitly adds support for it.
Related
I'm pretty sure this isn't how I'm supposed to use windeployqt, but I have an executable which is missing some dependencies (specifically the qt plugin windows). I thought I could use the windeployqt tool in order to find the missing dependencies for this executable and install them, but I get a "does not exist" error when I try and run the following:
windeployqt.exe ExecutableFileName.exe
I tried this after trying the full path (e.g. windeployqt.exe pathtoexecutablefile\executablefilename.exe
but both times I get two errors. Either filename.exe does not exist, or pathtofile\filename.exe doesn't exist. Is there a way to fix this or am I using the tool wrong? I've added the folder containing the tool to my system path, but do I need to add the folder containing the executable as well?
So I'm following the install instructions for Bazel 2.0, and basically it seems like all I have to do is download the ".exe" file, add it to the path, and then I can use it from windows powershell (probably bash too, although I haven't tried). What I want to know is - does the ".exe" file do any manipulation of my system (outside of the obvious compiling work) or download anything else under the hood? I ask because I want to try it out while working on a restricted computer system, as I'm sure some of you have encountered before.
It will extract itself into the location where it also (unless configured otherwise) keeps its build output. By default this would be under current user's home directory. The location can be changed with --output_user_root parameter or TEST_TMPDIR environmental variable. You can check out the docs for more detailed description.
Adding to Ondrej K.'s answer:
Yes, you just download the .exe and add it to your PATH. Do not run it from Bash though, because it's broken. (I'm linking to the documentation at master as of 2020-02-28 and as of 2.1.0 being the most recent version. The current master will become the release doc for 2.2.0.)
Yes, Bazel will download stuff. This includes tools for the languages you build (e.g. Java), and also external dependencies of the project.
Yes, Bazel will write to disk even if you just run it once: as Ondrej K. wrote, it will extract itself to a directory.
Do not set TEST_TMPDIR to tell Bazel where to run. Setting this envvar will make Bazel believe it's running inside a test, and it will significantly reduce its resource use and change its behavior in subtle ways you probably don't want. (If you want to limit its resource use, you can do so with several flags, see --jobs and --local_ram_resources, --local_cpu_resources.)
After installing cmake-3.8.1-win64-x64 I got thisenter image description here
So what can I do with this? Thanks.
cmake-gui does not help you create cmake configuration files, it parses these files to generate and configure projects.
In your source code directory, you should have a CMakeLists.txt file which defines the rules for CMAKE to configure your problem. That directory should be entered into the first box.
Next, you get to decide where to build the binaries. We could do it in the source directory, but the generated artifacts could pollute what is already there. "Cleaning" the build by deleting all of those artifacts while keeping the original sources is tedious at best, so it's a good idea to make an empty directory and use that as your binaries path.
Once you have those fields entered, you should be able to "Generate" or "Configure" your project. If you need help creating a CMakeLists.txt file (that's really the complicated part), then check out their tutorial.
I have a project which uses Makefiles. On a branch, I have CMake based build system. Now some team-members wants the OLD make-files based system intact, when cmake is added. But this is not possible after cmake . command overwrites the old Makefile.
Now I can easily avoid it if I can tell CMake to generate makefiles with some non-standard names e.g. makefile.cmake etc. Is it possible?
I am open to consider other options as well. In any case, old Makefiles must not be touched.
Cmake creates a build system in the working directory. So create any empty directory, and run cmake <path-to-source> from there.
Unfortunately, the name "Makefile" in hard-coded several times, in the sources of CMake. You cannot change it. As Peter has pointed out in the other answer, that change is not necessary, because CMake support out-of-source builds.
I am compiling an old version of GNU coreutils(version 6.10/6.11) using autotools. However when I do some modifications in the source code directory there will be some errors when generating man pages.
As I don't care about the manpage at all, I hope the default target doesn't include manpage's generation.
There might not be a general solution for all kinds of source code managed by autotools, however I believe there must be a typical approach, especially for GNU coreutils.
Any advice will be appreciated:-)
Regarding installation:
At least for projects like Libssh2 and LibCurl, you can just do a make install-exec instead of make install.
Conversely, if you just want the man pages, you should do a make install-data.
I am not sure if these targets exist in every autotools project though.
I don't think building manpages is a built-in task of any sort. I believe it is usually just a subdirectory or specific target that is being run. You can probably just find the part of the Makefile.am responsible for building the man page and disable it. Either by removing the SUBDIR entry for the directory or by removing whatever target references the manpages target.
The error is due to the correct path for manpages not being found ,which will be mostly docbooks.xsl (as it is for me). So find the docbooks path
find /usr -name docbooks.xsl
This will list all available paths related to docbooks.xsl.
Find the correct docbooks required by make and paste it in the file