I would like to know if that's possible to declare a dependency to a library via GIT. My usecase is simple, I have some tools, that I would like to share between my projects, but I don't want to add them to haxelib (because this tools are not really interesting for someone else). Otherwise, I would like that people who will install my lib, get my tools too (without the need to use manually haxelib git ....).
Is it possible ? (I didn't read anything about that in documentation)
This is currently not supported in Haxelib, though it would be great to see, and not too hard to implement. If you're interested in working on Haxelib, it's not too hard, open an Issue on the Haxelib Github project and perhaps we can help you figure out how to contribute.
One alternative if you need a workaround is to create a "run" script, so you can do:
# Run the project's run.n file
haxelib run mylib
# Your "run.n" file could have a "setup" command that runs
# the "haxelib git" commands for the user
haxelib run mylib setup
It's a bit of a hack, but it could work in the interim. See http://haxe.org/doc/haxelib/using_haxelib#runnable-project for more info on how to have a run script for your haxelib.
As of 2016, this is now natively supported by Haxelib. You can see the PR here.
As mentioned in the PR, you can use the one of these two:
haxelib git:<url> (similar to cloning the git repository).
haxelib git:<url>#commit-ish (clones to a specific commit, specify the hash.
Shameless plug, BUT you can checkout my http://lib.haxe.org/p/hxmlinstall/
1. Add -lib hxmlinstall to your hxml.
2. Annotate your tools like so
#git https://github.com/you/tools commithash
-lib forkedlib:git
On build you will be warned if your lib repository is not on specified %commithash%
Run haxelib run hxmlinstall to install / pull / update all dependencies
Related
I found https://github.com/mozilla/gecko-dev/tree/master/b2g Mozilla repositories where have the moz.build file, can anybody help, how I can build this plugin. What are tools I need use for build project with use moz.build ?
thank you
If you are trying to build B2G (Firefox OS), then you should follow the procedure documented here. But I have to advise you that you're using the wrong repository if that's your objective, since the correct one for B2G should be this.
In any case, you would need to install the build prerequisites for Linux, as described here, by using the following command:
wget -O bootstrap.py https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py && python bootstrap.py
Now, if you really wanted to just build the b2g folder in the repository you linked, once you've downloaded and installed the prerequisites, simply issue the following command from the root of gecko-dev:
./mach build b2g
This will invoke mach, the build system Mozilla uses, to build the code in the b2g directory.
I have a project with packages inside:
project package "root": a/b/c (eg github/b/c)
in a/b/c we have a lot of packages (p1, p2 ...)
project is managed according to How to Write Go Code official recommendations. The local project path is: $GOPATH/src/a/b/c. Also all imports are "not relative".
the project has go get-able dependencies
Now I want to use some dependency manager tool like gom or godep. Each of this tool creates an extra directory in repository and puts all vendor dependencies there. Also it plays with GOPATH and sets it to that vendor directory. Let's assume that the tool will put all vendors in path_to_project/.vendor - becoming a new GOPATH.
I want to use one of the go tools (gofmt, gorename, ...) being aware about packages in my projects and vendor directory. The problem is that if GOPATH=path_to_project/.vendor (godep does this) then tools are not aware about packages in my project.
One idea for this is to set a GOPATH=path_to_project/.vendor:GOPATH in a shell end editors. Or call every command with gom exec (gom sets a GOPATH in the above proposition)
Is there any ready and automatic solution for this?
Final goal is to bundle go project with specified dependencies versions (like git commits) and make tools + editors (vim/emacs) working with this tools.
If you are using godep, you can just prefix the go command with godep like this:
godep go build
or
godep go fmt
Existing build systems usually have some kind of install targets, that is used either manually (for installing in /usr/local or other location that user can access) or automatically (by package build systems of binary based distros or by package managers of source based ones).
What is the intended way of installing software that uses Cargo? How an analog of make install should look like?
Cargo itself uses additional configure/make stuff that handles configuration, detection of system dependencies, running cargo build and installation.
Is this the right way for any other software built with Cargo? It means are there plans to cover this tasks by Cargo itself or is Cargo intended only as a tool for dependency fetching and compilation without any configuration/detection of installed deps/installation?
Or are any plans to add this functionality?
cargo install
As of Rust 1.5 you can use cargo install to install binary crates onto your system. You can install crates from:
crates.io (the default), using cargo install crate_name
any git repository, using cargo install --git repository_url
any directory, using cargo install --path /path/to/crate
The first two have additional options you can specify:
With crates.io, you can use --vers to specify the crate version.
With git repositories, you can use --branch to set the branch to install from, --tag to specify the tagged release to use, and --rev to build from a specific commit.
Installation location:
cargo install can be configured to install in a custom directory through the following methods, in order of precedence (highest first):
By passing --root /path/to/directory (this path can be relative)
By setting the $CARGO_INSTALL_ROOT environment variable
By setting the install.root configuration key
By setting the $CARGO_HOME environment variable (which will affect more than the installation directory of cargo install)
If none of the above are present, cargo will install the crates in ~/.cargo/bin.
In all of the above cases, the output files will actually be placed in the bin subdirectory (e.g. --root /path/to/directory will actually place ouput in /path/to/directory/bin).
Uninstallation
cargo uninstall can be used to remove previously-installed crates. If you have multiple crates with the same name installed, you can specify --root to only remove the version in that directory.
Example: I want to use rustfmt:
I can use the version on crates.io:
cargo install rustfmt
I like using original releases:
cargo install rustfmt --vers 0.0.1
I want it installed in /opt/rust_crates:
cargo install rustfmt --root /opt/rust_crates
I really need to use the bleeding-edge version:
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git
The latest commit has a bug in it!
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --rev f5bd7b76e0185e8dd37ae6b1b5fb5e11187f0b8c
I truly desire the version that uses git submodules for its dependencies:
cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --branch submods
I've cloned it and made some edits:
cargo install --path ~/my_rustfmt
Actually, I insist on doing my formatting entirely manually:
cargo uninstall rustfmt
(This answer is intended for developers who want to distribute their own programs, not users who have received a Cargo project and need to install it on their own system; That's the domain of Toby's answer).
In addition to Toby's Answer:
Cargo's install feature is not meant to be the primary way to distribute Rust programs. It's designed to be used only for distribution to other Rust developers. There's several drawbacks to using this feature:
Cargo requires end-users to install the entire Rust toolchain first.
Users will have to build the program locally, which can be slow, especially in Rust.
There's no support for upgrading programs once they're installed (without an additional tool).
There's (currently) no way to include assets, such as documentation.
The packages will be installed only for the current user unless flags are passed to cargo install.
In other words, cargo install is the make && sudo make install of Cargo programs; It's not the ideal way to distribute a Rust program, unless it's intended primarily for Rust programmers.
So what is the correct way?
Let's look at the alternatives.
Manually distribute a tarball/zip
You can replicate the effects of cargo install by simply using cargo build --release. This will place a (mostly, see the drawbacks below) statically linked crate binary in target/release/crate_name, and this can be repackaged into a .tar.gz or .zip and given out to other users.
Pros:
Doesn't require users to install Rust or build the program themselves.
Allows developers to copy assets into the tarball/zip and distribute them along with the program itself.
Cons:
Installing a .tar.gz/.zip is nonstandard and generally not considered ideal for most users.
If the crate needs any system dependencies beyond libc, it will fail to load them with a difficult to understand error.
This requires a developer to manually build a package to release for each version and platform combination.
Use a CI service to build releases
It's possible to recreate any of these methods using a cloud-based CI service. For example, using Travis CI, you can use the Trust project to automatically deploy in much the same way that you would from a tarball, but automatically with only a tag being required.
Pros:
(All of the advantages of a tarball, plus)
The developers don't have to manually release the program, they just need to tag a release.
As a side effect, it's possible to build for every package the program supports at once.
Cons:
The process can be frustrating to debug if it doesn't work correctly, because there's limited control over the server.
The build process is tied to a service, which means releases can be missed if the service is down when they are released.
With Trust or similar tools, you're still ultimately distributing a .tar.gz/.zip, which means there's still inconvenience for users and a lack of system dependency management.
In addition to Travis, see Appveyor and GitHub Actions as possible build platforms.
Provide a package
This is considered the ideal method for many end users, and is the standard way to distribute any program, not just Cargo programs. This alleviates almost every issue with the tarball approach, though not without some problems of its own.
Pros:
Included in the system like any other program.
Can be submitted to Linux distribution repositories to allow programs to be installed in only one command.
Allows updating, removal, and asset inclusion.
Tracks system dependencies, which is especially helpful for GUI apps.
Cons:
By far the most complex of these options.
Requires building a package separately for every supported platform (this can be alleviated with CI, but it will be even more complex to setup this way.)
This approach is best handled with additional tools:
cargo-deb: Build a package for Debian and Ubuntu.
cargo-rpm: Build a package for Fedora, Red Hat, and CentOS.
cargo-aur: Build a package for Arch Linux.
cargo-wix: Make a Windows Installer package.
These usually are tools that are meant to be run by developers, to create the files that are used to generate packages. See their own documentation for more information.
Source: https://rust-cli.github.io/book/tutorial/packaging.html
I am newbie of Autotools. From my understanding, one would use the following basic steps to build software using Autotools:
autoreconf --install
./configure
make
However, I noticed that most open source software packages (on Linux) does not need the 1st step. Most of the time they just need step 2 and 3 to build. It seems that they already are packaged with a Makefile.in. I am wondering why? Do they manually code the Makefile.in, or does the software developer use autoreconf to generate the Makefile.in before creating the software package?
The software developer who creates the tarball (or who checks out the sources from a version control system) will usually invoke autoreconf from a script called bootstrap.sh or autogen.sh which may do other stuff. autoreconf might be invoked by Makefile as well (like when configure.ac has changed).
Most users will never need to run autoreconf, even those who are making some modifications to source (e.g. patches). Only those who need to make modifications to the package itself (making changes to configure.ac and/or Makefile.am) will need autoreconf.
Running autoreconf requires having the correct version of autotools installed already. This leads to a chicken-and-egg problem -- how do you get autotools installed in the first place? It also adds an extra dependency that most end-users don't really need.
As a result, most packagers run autoreconf before producing the source tarballs that they distribute. This means that if you download such a tarball, you can configure and build it without needing to install autotools first.
I have a question about the structure of the source code from a cygport package.
Here is the contents of a Cygports source file:
the actual source bundle for the project (tar.gz, tar.bz2, etc.)
the any number of *.patch files.
a .cygport file
I am trying to build gedit-3.4.2 from cygports repository.
How does the .cygport file help me run the proper options in the ./configure ?
For instance, in gedit if i don't specify --disable-spell it won't proceed due to error. How do I get the list of ./configure options that were used to build the project when the cygport was built?
Is there some way we can use the cygport executable to build the cygport and change the prefix too?
Here is the contents of gedit-3.4.2-1.cygport:
inherit python gnome2
DESCRIPTION="GNOME text editor"
PATCH_URI="3.4.2-cygwin.patch"
DEPEND="gnome-common gtk-doc
girepository(Gtk-3.0)
pkgconfig(enchant)
pkgconfig(gtksourceview-3.0)
pkgconfig(libpeas-gtk-1.0)"
PKG_NAMES="${PN} ${PN}-devel"
PKG_HINTS="setup devel"
gedit_CONTENTS="--exclude=gtk-doc --exclude=libgedit* etc/ usr/bin/ usr/lib/gedit/ ${PYTHON_SITELIB#/} usr/share/"
gedit_devel_CONTENTS="usr/include/ usr/lib/gedit/libgedit* usr/lib/pkgconfig/ usr/share/gtk-doc/"
DIFF_EXCLUDES="*.desktop.in *.schemas.in *-marshal.h"
CYGCONF_ARGS="--libexecdir=/usr/lib --enable-python"
KEEP_LA_FILES="none"
EDIT Someone from Cygwin Ports mailing list said:
"The configure options are
--libexecdir=/usr/lib --enable-python
Which is from CYGCONF_ARGS."
Here is the contents of a Cygports source file:
You'd do better to think of it as a Cygwin package source file.
cygport is simply a tool for automating the creation of Cygwin binary and source packages. It is the primary tool available, but unlike with some other packaging systems, there's really nothing forcing you to use it. It is quite possible to build a Cygwin package entirely by hand, since it is really nothing more than a tarball that Cygwin's setup.exe can blindly unpack into the Cygwin root directory (typically c:\cygwin) with the expectation that this will put the package's files in sensible locations.
Before cygport existed, people did build their own ad hoc packaging systems. Many Cygwin package maintainers still use these tools they created. (Yours truly included; two of my three packages use cygport, but the third still uses a custom build system.)
Ultimately, you want to read the cygport manual, in /usr/share/doc/cygport/manual.html.
(Yes, I know, "RTFM" answers are frowned on here. But, as one who currently maintains two cygport based packages in the official Cygwin package repository, please believe me when I tell you that the manual is still the single best resource available on this topic.)
How does the .cygport file help me run the proper options in the ./configure ?
As you found out through other resources, you'd first need to edit the CYGCONF_ARGS value in the .cygport file.
The simplest possible step after that is cygport gedit-3.4.2-1.cygport all. That attempts to rebuild all the binary packages in a single step. It also builds a new source package containing updated .cygport and patch files.
If something breaks in the all build process, it is usually faster to switch to using the sub-commands contained by all instead of completely restarting the process. The all step just runs prep, compile, install, package, and finish for you, in that order. For instance, if all fails during the compilation step, there's probably no need to repeat the prep step.
(It is exceptionally uncommon for cygport or a sane build system to wreck the build tree, forcing you to re-run prep. Far more commonly, you end up needing to re-do prep when you manually wreck the build tree while trying to get a new package to build for the first time and need to start over.)
For instance, in gedit if i don't specify --disable-spell it won't proceed due to error.
You can probably fix that by installing the libaspell-devel package from the official Cygwin package repository with setup.exe.
Personally, I wouldn't disable any feature unless it meant installing unofficial packages, such as those from the Cygwin Ports project.[*] It is nice to have Cygwin Ports repository, but because it contains so many packages, installing one can end up creating an "install the world" situation: package A depends on packages B, C and D, and C depends on E, F, G, H, and G depends on I, J, K, and... Dependency hierarchies within the Cygwin package repo tend to be flatter and narrower than those in the Cygports repo.
Is there some way we can use the cygport executable to build the cygport and change the prefix too?
You have guessed that you just add --prefix=/my/private/program/tree to CYGCONF_ARGS, I trust.
[*] If you are feeling confused about "Cygwin Ports" and cygport, the naming similarity is no coincidence. cygport is a tool created by Yaakov Selkowitz for himself when creating the Cygwin Ports package repository. Later, it became popular enough among other Cygwin package maintainers that it pushed out most of the competing build systems.