I found this: https://github.com/AndrewGaspar/cmake-cargo but couldn't make it work
Anyway, if I were to use a Makefile instead of CMake, I'd simply create a rule that watches for the .rs files to change and recompile.
I couldn't find a solution for calling Cargo from Cmake (not the other way around) so I'm opening one here.
How can I make my CMakeLists.txt watch for .rs file changes and recompile by calling cargo build?
I'm the author of the linked project in the OP. I apologize for the sorry state it was in when you found it, but in the last month or so I've invested a bunch of time to really flesh it out, and gave it a more inspiring name: https://github.com/AndrewGaspar/corrosion
I hope you could check out the latest README and let me know if you can get it working for your scenario. And if not, please file an issue, letting me know where in the documentation you ran into issues.
Following recommendations, I simply added the command cargo build as a dependency to my library
add_library(libsmoltcp_cpp ${libsmoltcp_cpp_sources})
add_custom_target(
lib_smol_tcp_rust
COMMAND cargo build
)
add_dependencies(libsmoltcp_cpp lib_smol_tcp_rust)
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.
I just switched to the last version of QtCreator (4.3.1) and the project explorer now shows many targets like ContinuousBuild, ContinuousConfigure, NightlyBuild, ExperimentalCoverage etc.
How can I remove all of these (or at least hide them) ?
I don't even know where this is generated in CMake.
Seems to be related to this question Hide automatically generated CTest targets except that I am not using CLion.
You are probably using somewhere:
include(CTest)
According to the documentation:
Configure a project for testing with CTest/CDash
All those targets are pulled in by the combination of the two, CTest and CDash (almost all of them are due to the latter actually).
If you don't know why they are there and for what they can be used, probably you are using the wrong command.
If all what you want is to use only CTest, add tests with add_test and run them with make test, replace the line above with this one:
enable_testing()
The documentation is quite clear indeed:
Enable testing for current directory and below.
Clean up the build directory and run cmake from scratch from within QtCreator. All the targets you mentioned should disappear.
I had exactly the same problem in a project of mine when I updated QtCreator a couple of months ago. You can see in the history of the project the commit that solved the issue. Pretty short indeed.
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.
This is a transitional solution.
I don't want to write my own plugin.
I have too many small, scattered makefiles to convert to pom.xml all at once.
I'm trying to move to Maven2 as a skunkworks project and gradually migrage new + changing code to pom.xml files.
The arch-independent C/C++ solutions are not needed - plus the Makefile run multiple scripts to generate code before compilation.
Any pointers to extending "mvn deploy" to handle "make deploy" would be great.
Thanks
AJ
You should check Codehaus' related CBUILDS project. It may help you with downloading dependencies, unpacking, patching, and invoking make.
I'm a bit confused as to why you're moving towards maven with C projects, but if I were you, I'd look at gmaven-plugin to execute an inline groovy script to invoke what you need. Then, if you want to create a plugin later, it should be easy to migrate to one.
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.