I am trying to configure my Intellij Clion IDE for working with ns-3. Since ns-3 is using waf, it is more tricky than i thought and would be really happy to hear any advice
CLion supports compilation databases for quite some while, which waf, luckily, is able to generate using the clang_compilation_database extension.
You'll need to load it within your configuration and option step; i.e. like this:
def options(ctx):
# Assuming you just copied the script into a directory called tools
ctx.load('clang_compilation_database', tooldir='tools')
# ...
def configure(ctx):
ctx.load('clang_compilation_database', tooldir='tools')
# ...
Now you can call waf clangdb; you'll be presented a file called 'compile_commands.json' in your build directory.
CLion only uses cmake for its internal project definition - so you have to have a cmake config.
It can be very simple and mirror parts of another build system you actually use, but how CLion treats files and what it does when you tell it to build something is defined by cmake and only cmake.
You could setup compilation databases as suggested by Julian or you could try my fork, if you don't mind using a not completely up-to-date fork of the upstream project. https://github.com/Gabrielcarvfer/NS3.
Visual Studio can also be used with CMake projects and WSL, but ClangCL/MSVC support is being worked on.
I plan on opening a MR to upstream the CMake support, but it is a lot of work to replace Waf completely.
Related
Some background: I am using Meson for an embedded C project. I have it working (example), but it isn't very clean.
The specific problem I would like to solve is including an out-of-tree Board Support Package (BSP) - a tree of headers and C files that act as initialization and abstraction code for a particular platform.
Previously I have been copying headers out of a vendor-provided BSP into my project on an as-needed basis, which does work, but there are disadvantages to doing this, the most important being the lack of reproducibility. Additionally, it causes duplication of code and makes it difficult to track where a particular bug came from if the bug is in the BSP.
The ways I have tried are:
Use an option in meson_options.txt to tell Meson where the BSP is on disk via meson configure. The issue with this method is that Meson throws an error during setup because options cannot be set until after setup is complete, and so it cannot find the requisite directories and refuses to continue.
Use a subproject and repeat the above - this causes the same issue.
I would ideally like the end-user to be able to set the BSP path with meson configure, instead of having to ever edit the build description (the whole point of Meson is to be user friendly!).
Is this possible? If it is not possible, why, and are there alternatives/common practice ways of doing this that I should know about?
In your question, you state that
options cannot be set until after setup is complete
That is not true. You can pass any option you want during the meson setup, using the following syntax:
$ meson <build dir> -D<option>=<value>
So I think the first way you tried to implement your option was correct, you just need to tell the user to set it directly during setup.
An existing Java project uses makefiles (which in turn uses ANT).
I want to work on this project using IntelliJ IDEA. However, no IntelliJ specific files, e.g. project files, should be checked in to version control.
How can I configure the project so that:
Makefiles can be run from inside IntelliJ IDEA.
Change Build > Make Project so that it either does nothing or runs some make target (in a makefile). I do not want to the standard behavior of compiling into ./bin since this potentially can conflict with the makefiles.
For Windows users
So far, the guidance provided by Dannil Maslov ( see intelliJ IDEA thread here ) worked for me.
Install GnuWin32 (Make for Windows).
Install the IDEA Makefile plugin.
Go to settings and specify the path to make executable under: File | Settings | Build, Execution, Deployment | Make | Path to Make executable (by default: C:\Program Files (x86)\GnuWin32\bin\make.exe). Check "Use Cygwin" if necessary.
If you have used chocolatey ( choco install make ) , change the path in step 3 accordingly.
You should be up and running.
A compilation database feature became available in 2018.
The help page says:
Make-based projects:
The compiledb-generator tool creates compilation databases for make-based build systems.
Bear and intercept-build tools:
Bear and intercept-build from scan-build are the tools to help you get a compilation database by intercepting compiler calls during the build.
(Bear and intercept-build work on Linux, by injecting themselves into LD_LIBRARY_PATH)
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.
The WebRTC library getting started guide explains how to compile the library.
The sample programs in ./trunk/talk/examples/peerconnection are not built, however, and there are no make files in those directories to do this.
Can someone explain how to compile this, and perhaps the other Talk example programs on Linux?
I've been able to build them using the ninja build tool. I don't know if building using make is supported as well.
When you've checked out the code, you should have subdirectories trunk/out/Debug and trunk/out/Release. In them, there should be build.ninja files. Just go to one of those directories and type ninja to start the build. The peerconnection executables will be peerconnection_client and peerconnection_server in the Debug or Release directory.
In case the ninja build files need to be regenerated, you can execute gyp_webrtc from the trunk/webrtc/build subirectory
E.g. how should I build release and debug version at the same time? I guess the answer make use of cache variables and some kind of "collection" of them.
Is it common way to get configuration params from cache params, isn'it ? If the answer is yes, how should I use several "collections" of them in a best way ?
Thanks a lot!
You don't specify the platform you are talking about. The Makefiles based generators will only build one configuration at a time, and the normal way to build several configurations is to use separate build trees, e.g. one for 64-bit Linux on Intel, one for 32-bit Windows, etc. Most CMake projects advise out of source builds, and assuming you wrote your CMakeLists files correctly you could have ~/src/YourProject, and ~/build/YourProject-Release, ~/build/YourProject-Debug.
This is the advised way to do it, assuming your source tree does not have any CMakeCache.txt etc in it. You can then run cmake -DCMAKE_BUILD_TYPE:STRING=Debug ~/src/YourProject in the debug directory, and similar for the release. This has the advantage that you can point dependent projects at the appropriate configuration.
The Boost CMake project has also explored building all configurations in the same build tree using library name mangling to differentiate. This may be worth looking at if you must build all configurations in the same build tree.
(for fellow googlers)
Be careful of not confusing build types and build configurations.
If you really mean "build types" such as debug and release and want to build them at the same time, then Cmake FAQ gives an answer : How can I build multiple modes without switching
Basically it involves using several out-of-source builds.