I've read the .travis.yml in the agda-stdlib project, while it's very different and complex from a simple library that was written in Agda purely (without those Haskell codes and Shell scripts).
I'm confused with the stdlib's .tarvis.yml. I've installed agda via cabal install, but the stdlib is trying to clone and compile Agda on Travis CI, and there're a lot of commands that seems to be irrealavent to building it.
Also, agda-stdlib seems to be available on Ubuntu's source. This could be the 3rd approach to install it.
Also, the stdlib doesn't have dependencies, but I have. I don't know how to add a dependency either.
Conclusion of my question:
In the 3 choices of installing agda listed above, which one should I choose?
How to add an dependency that let the agda compiler knows I'm actually using it?
The standard library is a bit of a special case: it evolves in lock-step with the development version of Agda. As such it is often the case that it cannot be compiled with a version of Agda readily available in your distribution of choice (e.g. because it uses syntax that was not available beforehand!) and it is forced to pull the latest version from github.
Installing Agda
If your library is compatible with a distributed version then it will be far simpler for you to simply pull it from the repositories via apt-get install agda.
Alternatively Scott Fleischman has a basic example on how to use a docker image to typecheck your development: https://github.com/scott-fleischman/agda-travis
Installing your dependencies
If your project relies on dependencies then you do need to install them. In practice it'll probably mean fetching a bunch of tarballs via wget, and having a ~/.agda/libraries pointing at their library files.
Cf. the manual on library management
Related
What's the ros way of linting ros code?
For ros1 I have found roslint but it is unclear to me if this is the recommended way to lint ros code and if it is still maintained/supported (last commit from three years ago).
For ros2 I couldn't find any official lint solution.
Not sure if there is "the ROS way of linting". For your Python/C++ code you can basically use any standard Python/C++ linter.
In addition (when using ROS 1) I can highly recommend catkin_lint, which checks the package definition and notifies about issues like inconsistent dependency declarations or missing install commands (especially the later can save a lot of time when moving from a devel workspace to installing packages on the robot).
The ROS2 development guide explains the rules used. Link1 and Link2
There is a linter located in ament_lint to enforce some rules.
To run the linter automatically as part of the tests of the package (use BUILD_TEST):
depend on ament_lint_auto and ament_lint_common:
Src file example Package.xml
<test_depend>ament_lint_auto</test_depend>
<test_depend>ament_lint_common</test_depend>
2 lines to your CMakeLists: (with BUILD_TEST)
Src file example CMakeList
find_package(ament_lint_auto REQUIRED)
ament_lint_auto_find_test_dependencies()
Bazel use CROSSTOOL files to figure out how to builds things. This can be used to (for example) switch between GCC and Clang by setting --crosstool_top. The problem is that it's far from trivial to construct those files.
Does anyone know of any tools that can inspect a Linux installation and generate the needed crosstool files for any "common" compiler(s) that happens to be installed? Something that would be able to find and support any installed versions of Clang and GCC would be enought, any other compilers (icc, etc.) would be fantastic.
(Alternatively: are there any repo's with pre-constructed crosstool files for default installations of all the common compilers?)
Note
I've already found #bazel_tools//tools/cpp:cc_configure.bzl et al. but those seem to only generate configs for the default system compiler and I'm specifically looking for support for the non default compiler(s).
It's only a variation on cc_configure, but you can use environment variables to tweak the generation. Maybe using CC will be enough? If not, what else would you need (pull requests welcomed)?
There is no repo with premade crosstools yet, there will eventually be (maybe in the form of docker containers, we'll see) but currently there's not.
I know that there are asciidoctor backends for reveal.js and deck.js but it seems that both are only available as ruby gems and not .jar packages.
While I know how to use the Gems from within a java build, I would like to use these backends without a reference to the ruby gem repository.
So are there already .jar packages available for those backends?
Maybe you could use gradle or maven to generate your slide-deck.
A third option might be to use asciidocctorj. At least the first two options are easy to use.
I know how to install LLVM/Clang/libc++ 3.8 on Travis CI, through the whitelisted llvm-toolchain-trusty-3.8, but this doesn't exist (or work) for 3.9.
Note the thing I need is libc++experimental.a, which contains the implementation of std::experimental::filesystem for libc++.
I really find the Travis-CI way of doing things kind of inflexible, so if there is a wholly alternative way of getting specific versions of things installed on a build machine, please enlighten me and free me from these stupid limitations. I also don't want to build every single toolchain dependency on Travis, that would be overkill.
The best way to get new libc++ in Travis-CI is to build it from source after installing LLVM/Clang.
Here is the script I wrote to download, build and install libc++ for Travis, and here is an example usage in Google Benchmarks .travis.yml. The script takes about 120 seconds to complete.
PS. I'm happy to see people using libc++'s std::experimental::filesystem :-)
You can install packages with apt addon into your container-based image.
Add next lines to your .travis.yml
addons:
apt:
sources:
- llvm-toolchain-trusty-3.9
packages:
- clang-3.9
- libc++-dev
- libc++abi-dev
Side note: At the moment you have posted your question llvm-toolchain-trusty-3.9 were whitelisted
I have a Rails project that is going to be using OpenCV, and it depends on a certain version of it (2.4.6.1).
I'm looking for deployment advice. The Ubuntu opencv package is an earlier version and therefore not suitable.
I can see a number of possibilities, but I'm trying to think of what will work best.
Just write it up in a README and expect people to follow it: download this, apt-get that, etc...
Add opencv, tagged at the version we need, as a git subtree, and include a Rake task to build it.
Write a script to download and compile the needed code.
Something else ?
None of them seem all that great, to tell the truth.
Can your application be made to work with OpenCV 2.4.2? That is available in Ubuntu 13.04, and you could request it be backported to 12.04. If not, you could update the source package to 2.4.6.1 (which would require learning about debian packaging but might not be too difficult since you would be modifying an existing package instead of starting from scratch), upload it to a PPA, and instruct your users on Ubuntu to install OpenCV from there. You could also package your rails application and put it in the PPA, which would make overall installation even easier.