Why does NS3 build every time I run a file - ns-3

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.

Related

In CLion, can you start a build on a specific file?

I'm doing some refactoring (more than what CLion can do automatically) and making lots of changes. When I change a header file, it prompts a significant fraction of my project to rebuild, but I know the error messages will always come from the same spot (which unfortunately starts with "w").
Is there any way to control where CLion will start building so I don't have to wait 30s+ to get the next error message?
I've been typing make src/workflow.o in a console (I tried using the CLion console, but that doesn't make links from errors), but I'd rather have the direct links to the error location.
You can add another cmake target to build only the stuff you need.
See e.g. here:
https://www.jetbrains.com/help/clion/2016.1/creating-and-editing-run-debug-configurations.html?origin=old_help

Atlassian Bamboo: don't trigger build if changes were made to a specific file

I have a plan in Bamboo that starts whenever changes are made to the attached repositories (via polling).
Now, on each build, if successful, a CHANGELOG file is updated in the repo, which in turn, triggers another build. How can I omit certain files from Bamboo's polling, so that a build isn't started if changes are found for those files? Because otherwise, I enter in infinite loop, with a change to CHANGELOG triggering another build which in turn updated CHANGELOG and so on.
If this is not possible, what other viable solutions are there? Is it possible to attach a shell script somewhere before the build starts to check whether it's desired to start a new build?
It turned out that this was simpler than I've thought. In Plan Configuration, in the Repositories tab, on each repository, under Advanced, there is an Include / exclude files input where you can Customise what files Bamboo uses to detect changes. By adding a regular expression there, I got everything solved and working as expected.
Bamboo pattern matching reference: https://confluence.atlassian.com/display/BAMBOO/Pattern+matching+reference
The Bamboo Documentation says:
Bamboo will ignore build triggers if the local working copy and the
repository copy have the same revision numbers.
This might not be the best solution, but you might add an additional task at the end of the job/build which updates the repository again to avoid triggering a new build.
I'm not sure if this would then skip builds from repository updates which occur during the current build.

Xcode custom shell scripts are slowing down the compiling time

Testing any changes to my Xcode project has become an exercise in patience whenever I build. After all the source files have compiled, I get the following message in the activity window at the top of Xcode:
"Running 3 of 3 Custom Shell Scripts"
I have not added any of my own custom shell scripts but I am using quite a few dependencies via Cocoapods and I am using 2 frameworks for the build environment, Crashlytics and Tapstream. Crashlytics requires you add a run script in the build phases, other than that I don't know where the other ones are coming from and they appear to be the bottleneck in my build time.
Can anyone enlighten me as to what is going on and how i possibly speed it up?
I can't enlighten you but I can tell you how I stopped mine from running. This also happened after installing Cocoapods. In my main project's Target, under Build Phases, I noticed two entries entitled Check Pods Manifest.lock and another called Copy Pods Resources.
Under both there was an unchecked option Run script only when installing. I checked both and at least for now my projects build and run fine without running the scripts.
This is kind of a crappy answer because I can't really give you any more information, and it might not even work for your case, so hopefully someone comes along and enlightens us.
POSSIBLE EXTERNAL BUNDLE ISSUES
So I just had a frustrating experience debugging an issue where a pod installed library's NSLocalized strings file weren't working. Turns out it was because I checked the option mentioned above. Pods-resources.sh, which had the lines to install the bundle, wasn't running in debug mode. It was only running when installing - of course! Something to watch out for.
More info in this question:
NSLocalizedStringFromTable not working in CocoaPod dependency
To fix the slow "Copy pods resources" problem I figured out a solution to only copy the resources if they haven't been copied before.
For this purpose we have to patch the *-resources.sh files that are created by cocoapods such that the copy procedure only happens if a generated file in the target directory doesn't exist (it is created upon first copy). As long as this target directory exists and includes this autogenerated file, the copy resources phase is skipped. This saves me about 30 seconds in my project (of course depends on your project size). To accomplish this do the following:
Create a patch file called 'copy_pod_resources_once.patch' in your project root dir with the following contents:
5a6,13
> NONCE_FILE="${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/copyresources-done.nonce"
> if [ -f "$NONCE_FILE" ]; then
> echo "already copied resources"
> exit 0
> else
> touch "$NONCE_FILE"
> fi
>
In the Podfile for your project add the following post install hook:
post_install do |installer_representation|
system('find "./Pods/Target Support Files" -name "*-resources.sh" | xargs -I{} patch -p0 {} -i ./copy_pod_resources_once.patch')
<other post install stuff>
end
For me, it was Crashlytics. There were some outstanding changes, as Crashlytics does auto-updating of its files. I reset/removed them and rebuilt and got past it.
So the general answer may be to check any third party components and make sure they're working properly.
As Ramsel has said in this answer,
https://stackoverflow.com/a/21318086/1752988
I also went to Build Phases and cleared out all the possible links to PODs, after trying most of the other solutions and the three build issues shown regarding Pods were cleared out.
But then one file which was not list under the XCode Project navigator was missing, but they were in the Downloaded Git Zip folder! Obviously, I copied it and put into the XCode project and try running it runs cleanly! :)
I had a similar issue in my project (however not using Cocoapods). It ended up being an issue with an application external to Xcode (Spritebuilder) somehow holding onto a resource within my Xcode project when it crashed. I forced the non-xcode application to close and now the issue is gone
Check your project folder name have any space.Because space creates problem in directory path like "SRCROOT".I removed spaces and project run fine.
I've found that this happens to me frequently. Exact cause unknown, but appears to be switching between git branches that have differences in what pods are being used. In my case simply touching the Pods-xxx-Resources.sh shell script file causes it to speed back up.
Probably not going to work for you, but cleaning the project fixed it for me (Product -> Clean)

CMake Fails until you remove CMake Cache

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.

Pre-Pre-build Steps in Hudson

I'm in a bit of a pickle. I'm trying to run some environmental scripts before I run the build in a m2 project, but it seems no matter how hard I try - the 'pre' build script are never run early enough.
Before the 'pre-build' scripts are run, the project checks to see if the correct files are in the workspace - files that won't be there until the scripts I've written are executed.
To make them 'pre-build', I'm using the M2 Extra Steps plugin - but's it's not 'pre' enough.
Has anyone got any suggestions as to how I can carry out what I want to do?
Cheers.
Have you considered breaking it up into two projects, and setting the pre-build project to be upstream of the build project?
e.g.,
Foo Pre-build
Foo Build
After Foo Pre-build runs, cause "Foo Build" to run.
I have used this, admittedly in different scenarios than yours, quite successfully. This has the added benefit (if you need it) of allowing you to manually run a build without going through the pre-build steps, if you know they aren't necessary.
You should use the free form project type and not the maven project type.
If this is a problem (ie, there are projects that are expecting to be triggered by or triggering from), consider using a custom workspace location and having a free form project execute in this workspace before the maven project runs. The free form project can be used as the trigger for the maven project.
Does adding another build step as a shell script work?
My problem stemmed from the fact I wanted to set-up my workspace before I ran anything due to an issue with Dynamic Views (ClearCase) not being accessible from the workspace - I wanted to add a symlink to fix this.
However, Andrew Bayer has made a change to the plugin that I'm currently testing that should fix this...so the question is probably invalid in it's current form.
Will edit it once we come to a conclusion.