With GPRBuild, I have created a library project called Lib. All packages in Lib reside within the package Base, which I use as a base package: to have a base package Base. For instance, if I were to create package Apple in any library or application I make, it would be written out as package Base.Apple.
The problem with this, using GPRBuild. In order to put things under the Base package, it needs to exist. In the GPRBuild library project Lib, I therefore have a file base.ads denoting the existance of package Base. Then in the project where I'm using the library Lib, let's refer to it as Proj, I also put all my packages under the Base package (the packages inside Proj). In order to do so, we need to create a base.ads file for Proj too with the package definition for just that, Base.
Let's have a look at the gpr project file:
with "lib.gpr";
project Proj is
-- ...
end Proj;
Through this arises the problem; we suddenly have two files, both called base.ads, both defining the Base package, one in each project: the library project Lib, and the project Proj using the library Lib. As we have two packages (and their files) named the same thing, we get this error, which at all is not surprising, at compile time:
unit "base" cannot belong to several projects
The question is: is there a way to have the same base package in multiple projects? Projects that are then linked together through an import (with). If it should prove to be possible, how can it be achieved?
You need to put the Base package in a project of its own. The following is a minimal demo.
In base/,
project Base is
end Base;
package Base is
end Base;
In lib/,
with "../base/base.gpr";
project Lib is
end Lib;
package Base.Lib is
end Base.Lib;
In proj/,
with "../lib/lib.gpr";
project Proj is
end Proj;
with Base.Lib;
package Base.Proj is
end Base.Proj;
Then,
$ cd proj/
$ gprbuild
using project file proj.gpr
Compile
[Ada] base.ads
[Ada] base-lib.ads
[Ada] base-proj.ads
Related
is there a way to setup a virtual environment in Julia using an environment file? (for instance like .yml file for creating conda venv)
Julia Version: 1.7.1
OS: Windows 10
In Julia virtual environment is defined via Project.toml file (that keeps package names and their acceptable versions) and Manifest.toml (that keeps the exact dependence tree and package versions generated along requirements defined in Project.toml).
Here is a sample Julia session:
julia> using Pkg
julia> pkg"generate MyProject"
Generating project MyProject:
MyProject/Project.toml
MyProject/src/MyProject.jl
julia> cd("MyProject")
julia> pkg"activate ."
Activating environment at `/home/ubuntu/MyProject/Project.toml`
Finally, note that you can manipulate the Project.toml by eg. adding a package like this (this assumes the environment is active):
pkg"add DataFrames"
Sometimes you want to provide package version information to your Project.toml, for an example you could add at the end of the file:
[compat]
DataFrames = "1.3.0"
After adding the first dependency the Mainifest.toml file has been generated. Copying this file together with Project.toml across machines allows you to duplicate the environment.
In order to have all packages installed on a new machine you will need to run:
pkg"activate ."
pkg"instatiate"
pkg"instatiate" can also be used to generate Mainfest.toml when only the Project.toml is present.
The nice thing is that Julia can store many package versions simultaneously and the virtual environments only links to the central package repository (contrary to Python that copies several GBs of data each time).
pkg provides this with project.toml files.
open julia in console
julia>]
Pkg> activate <Name>
<Name> Pkg> add <PackageName>
create directory with
Per the Julia Docs:
The build step is executed the first time a package is installed or when explicitly invoked with build. A package is built by executing the file deps/build.jl.
Why would I want to make a build.jl file and how do I effectively utilize the benefits it allows for?
Typically (historically) the build step and the build.jl file is used for downloading/installing binary dependencies with e.g. BinaryProvider (or its predecessor BinDeps)1. The build step can also be used to install configuration files. For example, IJulia uses build.jl in order to install a Julia kernel for Jupyter.
If your package is pure Julia code you typically don't have a build.jl file since there is no need for it.
1 With Julia 1.3 we have Artifacts which is meant to replace the BinaryProvider workflow and make build.jl obsolete for the purpose of downloading and installing prebuilt binaries.
I have a local package that I am writing. I wanted to extend some functionality from a few of the core meteor packages. In order to do this, I was creating another local package.
So now local package A is attempting to use local package B. But even after adding the symlink to package A's packages folder, I get an unknown package error when running test-packages.
meteor add local-package-b
Doesn't work because meteor complains: You're not in a Meteor project directory
Is this even possible or do I need to publish to atmosphere first? I wanted to keep the additional package local as it's going to be a handful of helper methods.
I've double checked the name in package B's package.js file and it matches with my api.use in package A's package.js file.
Symlinks shouldn't be necessary here. Local packages are found by checking:
Anything under the directory pointed to by the environment variable PACKAGE_DIRS.
Anything under the packages directory in the current application directory.
Core packages.
As long as your two packages reside in one of those three locations, the should be found. Also see my article on local packaes for more details on (1).
Based on our conversation below, the main issue had to do with the approach to creating a new package. While it's being written, it's necessary that a package be added to (or tested by) an app. Here are the steps I take when working on a shared, local package:
Create a new app.
meteor create --package mypackage
meteor add mypackage
Finish writing and testing the package.
Move mypackage under my PACKAGE_DIRS directory so it will be available to other apps.
I need to link to R library and have seen some pointers on the Web - all referencing Rdll.lib file.
However, in my installation directory \R\R-3.1.2\bin\x64 contains only DLL file - R.dll.
Does the default installation of R ships a library and if yes, where to find it?
As a note, this all relates to attempts to create an R wrapper for C++ library with SWIG
You need to manually build the Rdll.lib. Instruction can be found in R folder in the doc/README.packages (at least for my 3.1.3 R installation):
First build the import library Rdll.lib by (from the sources)
make R.exp
lib /def:R.exp /out:Rdll.lib
or, depending on your version of VC++:
link /lib /def:R.exp /machine:x86 /out:Rdll.lib
Does R have a dependency management tool to facilitate project-specific dependencies? I'm looking for something akin to Java's maven, Ruby's bundler, Python's virtualenv, Node's npm, etc.
I'm aware of the "Depends" clause in the DESCRIPTION file, as well as the R_LIBS facility, but these don't seem to work in concert to provide a solution to some very common workflows.
I'd essentially like to be able to check out a project and run a single command to build and test the project. The command should install any required packages into a project-specific library without affecting the global R installation. E.g.:
my_project/.Rlibs/*
Unfortunately, Depends: within the DESCRIPTION: file is all you get for the following reasons:
R itself is reasonably cross-platform, but that means we need this to work across platforms and OSs
Encoding Depends: beyond R packages requires encoding the Depends in a portable manner across operating systems---good luck encoding even something simple such as 'a PNG graphics library' in a way that can be resolved unambiguously across systems
Windows does not have a package manager
AFAIK OS X does not have a package manager that mixes what Apple ships and what other Open Source projects provide
Even among Linux distributions, you do not get consistency: just take RStudio as an example which comes in two packages (which all provide their dependencies!) for RedHat/Fedora and Debian/Ubuntu
This is a hard problem.
The packrat package is precisely meant to achieve the following:
install any required packages into a project-specific library without affecting the global R installation
It allows installing different versions of the same packages in different project-local package libraries.
I am adding this answer even though this question is 5 years old, because this solution apparently didn't exist yet at the time the question was asked (as far as I can tell, packrat first appeared on CRAN in 2014).
Update (November 2019)
The new R package renv replaced packrat.
As a stop-gap, I've written a new rbundler package. It installs project dependencies into a project-specific subdirectory (e.g. <PROJECT>/.Rbundle), allowing the user to avoid using global libraries.
rbundler on Github
rbundler on CRAN
We've been using rbundler at Opower for a few months now and have seen a huge improvement in developer workflow, testability, and maintainability of internal packages. Combined with our internal package repository, we have been able to stabilize development of a dozen or so packages for use in production applications.
A common workflow:
Check out a project from github
cd into the project directory
Fire up R
From the R console:
library(rbundler)
bundle('.')
All dependencies will be installed into ./.Rbundle, and an .Renviron file will be created with the following contents:
R_LIBS_USER='.Rbundle'
Any R operations run from within this project directory will adhere to the project-speciic library and package dependencies. Note that, while this method uses the package DESCRIPTION to define dependencies, it needn't have an actual package structure. Thus, rbundler becomes a general tool for managing an R project, whether it be a simple script or a full-blown package.
You could use the following workflow:
1) create a script file, which contains everything you want to setup and store it in your projectd directory as e.g. projectInit.R
2) source this script from your .Rprofile (or any other file executed by R at startup) with a try statement
try(source("./projectInit.R"), silent=TRUE)
This will guarantee that even when no projectInit.R is found, R starts without error message
3) if you start R in your project directory, the projectInit.R file will be sourced if present in the directory and you are ready to go
This is from a Linux perspective, but should work in the same way under windows and Mac as well.