I'm Using Bower to install dependencies and using RequireJS's r.js.
But when using r.js to build, all of the bower-components are also included (tests, docs, non-minized js etc). As it's nice to have tests included with each components in my dev directory, I find it a hassle to deal with when using r.js.
How would I setup a app.build.js file for r.js, that only includes the needed dependencies?
There is an option skipDirOptimize which should do what you want.
Related
Let's say I have two projects. Lib and App.
App has Lib in it's conanfile.txt. Normally when conan install of App's dependencies is performed conan downloads and compiles Lib to ~/.conan/data/.
Is it possible to link App to Lib that is currently being worked on instead (e.g. /home/path/to/code/Lib/cmake-build-release/lib/ )?
The reason I want to do this is to debug a Lib's bug whose only known way to reproduce is by using App. I want to be able to quickly add std::cout to certain places and incrementally recompile. Rebuilding the whole conan package and doing conan install each time is too long. I was thinking about some hack that would change include path and linking path.
Yes, it is possible, Conan uses the same approach as Python pip: the "editable" packages. You can read more about it in this section of the docs: Editable packages. The basic idea is:
You cd libfolder and define it as a package in edition: conan editable add lib/1.0
You can build the lib there, like conan install . + cmake .. or conan build .
You can go to the App folder cd appfolder and do a conan install .. You should see that lib/1.0 is marked as "editable" and not from the Conan cache. You can build App, and it will be linking your dependency to lib from the local libfolder.
Every change that you do to libfolder and build there locally (incremental builds), will be directly available to App without needing to create or export-pkg to the Conan cache.
The editable feature relies on the correct definition in lib/1.0 of the project layout, in its layout() method. There are built-in layouts like cmake_layout(self).
If the different packages lib and app generate compatible projects, like Visual Studio, it is possible to join those projects in the IDE and have a convenient development and debugging experience of both packages together. There is a live demo in this C++ Italian Meetup presentation
I'm new to Bazel and Armeria. In the Armeria dev guide, in setting up with a build system, it has examples from Gradle and Maven, but not Bazel. Downloading the jar file (armeria-1.18.0.jar) and importing it directly using java_import() will build the project, but gives and error during runtime. It cannot find the runtime dependencies of Armeria like micrometer, etc.
This seems more like a question about bazel rather than armeria.
Have you tried using maven_install? I guess this takes care of pulling in transitive dependencies.
Sample: https://github.com/bazelbuild/examples/tree/main/java-maven
Documentation: https://github.com/bazelbuild/rules_jvm_external
I'm upgrading an existing project from OL3 to OL6.
That includes some customised extensions to OL which I need to forward port.
What I can't seem to find, is the process to simply rebuild the library from source, to produce the same set of files (with our customisations) as here: https://github.com/openlayers/openlayers/releases/download/v6.14.1/6.14.1-dist.zip
To build the "legacy" ol.js library in npm, use:
npm run-script build-legacy
(with the correct dependencies, npm, shx; I got the openlayers source by cloning it in git)
I have recently started learning meson and I am testing switching to it (from CMake) in one of my projects. The problem is that I usually use cpack to build the project's packages/installers, and after scouring the meson docs for something similar to cpack I am unable to find anything.
Requirements/what I currently use cpack for
Single script to automatically build and package binary releases (such as deb, rpm, windows installer, etc)
Integrates with the build system - Picks up targets automatically, doesn't require redefining installation logic or structure
Supports building at least deb packages and a windows installer (don't care which)
There is the information on building release archives and then using scripts to process them with packaging tools (such as inno). However, this is not really what I am looking for as it is far more awkward and inflexible than cpack (i.e I have to change 3 different scripts if the directory structure changes).
Ultimately I can learn to use the meson system and manually write packaging scripts, no doubt it will make me a better scripter, however, I am eager to know if there is a better way of doing this which is not advertised in the docs or if there is some unofficial project which will automate the process.
Edit
By package I mean like a deb package - a package for a system package manager, not something like conan
I suggest that you use conan. Please take a look at conan configuration in the Meson.
It might be worth considering using meson rpm packaging module RPM module:
It autodetects installed files, dependencies and so on
This module as of now supports only generation of RPM spec file:
rpm = import('rpm')
rpm.generate_spec_template()
What is the difference of having the packages under the dependencies or devDependencies in the package.json?
How does that impact in the final build?
Sounds quite simple, but I don't have it clear to which packages to put in each section. Even similar addon's documentations vary as well, some say to use --save and others --save-dev, which confuses me.
In an ember app all your dependencies will go under devDependencies since you build the app via the ember cli and you do not include the app in another project.
For addons the story is a bit different, if your addon exposes any functionality from a package then that package has to be under dependencies.
Take a look in your package.json file and you will see two types of dependencies. One is called devDependencies(usually modules needed for local development) and one is called dependencies (dependencies used in production or that are integral to the given project). The --save flag adds your dependencies to the dependencies object of your package.json file and --save-dev adds your dependencies to the devDependencies. They're separated for convenience.
Edit:
This question has been answered before, but the tldr; is, it doesn't affect your production build. Hope that this helps.