I have a project that I am managing using CMake and I have run into some very strange behavior that I don't understand. If I clear out my build directory, run cmake, run make, then run my program my program crashes every time because I fail an assertion somewhere in pthreads/boost threads. No matter how many times I make, and make clean this project it crashes every time I run it. However, if I then remove CMaketCache.txt, regenerate my makefiles, build and run, the program runs as expected every time.
In summary I need to follow the following steps for my code to work...
Run Cmake
Run Make
rm CMakeCache.txt
Run Make
Run program
It appears that the Make files before and after I remove CMakeCache.txt differ. What could explain this behavior?
Do you have git installed? If so, you can use this trick:
Run cmake
make
git add .
git commit -m ""
rm CMakeCache.txt
run make
git diff
Some odd things I can see in what you are saying. I don't see why your program would recompile anything just because you removed the CMakeCache.txt. Everything should be up-to-date from the first make, so something is bad there... My guess is that it is finding a different thread library or no thread library the second time.
Related
I am working on NS3 and I am using the ./ns3 cmake wrapper to run my .cc files. The issue is that the ns3 builds all the dependencies every time i run a file, even when there are no code changes. Is this expected? This is really hogging my time and I see in the NS3 manual that it should not build every single time, and builds only what is necessary
The behavior you report should not be happening, especially if you are using the latest ns-3.36.1 release. If it is with that release or later, please file an issue with enough details for a maintainer to try to reproduce the issue. In any case, you can suppress even checking whether a new build is needed by passing the --no-build option to ./ns3 run command.
For the same project, I work both in the Bazel IntelliJ plugin and the command-line.
Whenever I re "Sync Project with BUILD files" from within IntelliJ, or do a new bazel build from the command-line, whichever one I have done last forces the other one to do a full rebuild of my project (with 100s of targets).
For example, if I run a test from within IntelliJ, and then do something from the command line like bazel build //... or even run the same test from the CLI, I get:
$ bazel test //foo:bar
INFO: Build options have changed, discarding analysis cache.
...
which is forcing my project to rebuild Protobuf and other native things that are not quick.
Why is this?
I can see that when IntelliJ invokes a test, for example, it has this full set of arguments to the bazel command, which I never specify any of at the CLI:
/usr/local/bin/bazel test --tool_tag=ijwb:IDEA:ultimate \
--curses=no --color=yes --experimental_ui=no \
--progress_in_terminal_title=no --runs_per_test=1 \
--flaky_test_attempts=1 \
--build_event_binary_file=/var/folders/08/fk59w_xd4zz2phs6q6r3r5mc0000gn/T/intellij-bep-b37bc093-86b4-4a03-9599-a45e7285f6ac \
--nobuild_event_binary_file_path_conversion \
--test_filter=com.spotify.spyglass.knightcrock.CommitInfoParserTest#
-- //knightcrock-consumer:CommitInfoParserTest
What I am experiencing is exactly what is described in https://github.com/bazelbuild/bazel/issues/3433, which was closed without much comment for being opened in the wrong place.
The specific option that's causing analysis to be rerun is --test_filter. The other options shouldn't affect the build configuration, so if you specify the same test filter on the command line, you shouldn't see analysis being rerun.
Fixing this so that not all analysis is rerun requires configuration trimming, which is a large effort that's actively being worked on.
Note though that only analysis should be rerunning. There's still a local action cache, so bazel should be noticing that not everything needs to actually be rebuilt. It might be good to confirm this by running with --subcommands to see what bazel runs when you try from the command line with a different --test_filter.
Also, it's probably worth filing an issue about printing which options caused the analysis cache to be dropped, so that it's easier to diagnose this sort of thing.
I'm working on a project that uses the proxygen library by facebook.
The latter builds itself by means of a script called deps.sh which uses to invoke apt-get as a super user.
I've successfully created a custom target with cmake using the add_custom_target directive, but it fails because of the above call with the error sudo: no tty present and no askpass program specified and it makes sense, of course.
Anyway I've not been able to find a way of executing that script, thus invoking a command as a super user, using the add_custom_target.
I can safely install the library and write a FindProxygen module for my colleagues, so that the build process remains coherent, but I'd like to know if there is a clean solution to the problem of launching a command as root from cmake and thus put the library as a submodule of the project.
You can run installation script in new terminal, so sudo, executed by this script, will work as usual.
COMMAND x-terminal-emulator -e "<...>/deps.sh"
(This may be written as part of add_custom_target, add_custom_command, execute_process, etc.)
add_custom_target(
apt-downloads ALL
COMMAND sudo apt install -y ${DEPENDENCY_LIBRARIES}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT "download required dependencies straight from apt on ubuntu"
)
Worked for me
The response is pretty simple: no.
As remarked in the comments, cmake expects to find all the required libraries already installed in the system (or at least, within the search paths) and any other solution would stop the execution and wait for user inputs.
As far as I've seen around, the usual approach, the one I've used too in the above mentioned project and in another one started immediately after, is to create a script that is in charge to download, compile and prepare the project environment, the same way proxygen itself does.
The final user will be asked to firstly executes that script, thus he will be able to proceed using cmake.
That's all, thank you for the comments.
Maybe this seems like a naive question.
I have some functionality in my project that suddenly doesn't work, an when I "Clean and Build", it works again.
What might be the problem that is being solved by performing this Clean and Build?
Your input is highly appreciated.
The actions on a Make and clean are derermined by the makefile. You can look at the Makefile itself to see what is there.
make by itself corresponds to the very first rule in the makefile.
make clean corresponds to the clean rule in the makefile
Also, you can use
make -n
and
make -n clean
These will show you the sequence of command(s) that are actually executed when make or make clean are run.
As a general convention, make by itself is a rule for compiling so it executes the compile commands necessary to build the project.
make clean is used for cleaning the project. It deletes the object files and the executable, and any other files necessary to allow a clean build of the project on next make.
Why doing make clean followed by a make helps?
It can be due to a number of reasons and its hard for me to tell you what may be going on. Can you give some more details on the failure mode?
with help of "build and clean" you can remove the old build files and make the new files.so that the updates will be effectively shown in the views.
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.