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
Related
I'm using autoconf & automake in a C project. I'd like to create a .deb package, so I have the following control.in file:
Source: myproject
Section: misc
Priority: optional
Maintainer: Paul Walker <pwalk#test.it>
Build-Depends: debhelper (>=9), autotools-dev#MORE_DEPENDENCIES#
Standards-Version: 1.0.0
Homepage: https://www.my-website.it/
...
I'd like to configure this file with autoconf since there might be MORE_DEPENDENCIES according to some configure-time flag I did set.
This control.in file sits in a stubs/ folder, after substituting the MORE_DEPENDENCIES variable, I'd also like to copy the resulting control file into the final destination folder debian/ to create the .deb package.
So essentially I'm trying to have autoconf do the following:
Include {srcdir}/stubs/ as input folder in order to substitute macros in the .in file sitting there
Configure the stub {srcdir}/stubs/control.in, substitute whatever macro is in there, generate the file {srcdir}/stubs/control with substituted macros
Copy {srcdir}/stubs/control into the final destination folder {srcdir}/debian/control
I've been looking for examples or in the official documentation but still can't find how to configure a .in file outside of the root source folder.
Regarding 'how to copy the final file to the debian/ folder' I suppose I could use a symlink ? Is there any better way?
This is a top-of-the-foodchain problem.
The Debian packaging tools are designed to be the top-level tool for building Debian packages, and the control file is supposed to stay unchanged for the entire run of a package build. You can probably fudge your way around that if you only wish to build binary packages, but then there would be no point in modifying the build dependencies because they are evaluated earlier.
The normal build process will distclean the build tree in order to record changes in the source package, then rerun configure and build. If you update debian/control at this point, the results are undefined.
If you have to update debian/control programmatically, use a separate mechanism that is not reachable from the regular package build. If you have regular releases rather than cutting packages from development versions, it might even make more sense to treat the packaging as separate.
I have completed a small project that uses several libraries. the CMakeList.txt looks like this:
cmake_minimum_required(VERSION 3.5)
project(tf_ct_log C)
set(CMAKE_C_STANDARD 99)
include_directories(include /usr/local/include/hiredis /usr/include/openssl)
link_directories(/usr/lib/x86_64-linux-gnu)
set(HDR include/ct_logger.h)
add_executable(tf_ct_logger src/main.c src/ct_logger.c ${HDR})
find_package(OpenSSL REQUIRED)
find_package(Threads REQUIRED)
find_library(PostgreSQL REQUIRED)
find_library(jansson REQUIRED)
target_link_libraries(tf_ct_logger OpenSSL::SSL jansson pthread pq)
I would like to be able to build a package that can be installed in another machine, without downloading any dependencies. with ldd, I 've got all dependencies of the application and copied those files (libxyz.so...) into a subdirectory deps in my project. How can I create that package using those dependencies so that the end user will just use the object files of my project along with the dependencies libraries to create the executable?
It gets really hairy real quick when you need to create a native package for multiple flavors of installers (Debian, RH, Arch, etc.), especially if customization is involved.
If you just need a clean reproducible to get it on a box and run -- I would strongly suggest looking towards packaging it as a Docker container.
You start from some lightweight Linux distro container (Alpine is the latest trend), derive it into one with C and C++ runtime and anything else you depend on and call this "my prod container". From that you derive one with C++ compiler and debugger installed and call it "my dev container".
We actually wrote a little memo a while back, while making our open source hobby usable for others.
You will probably still need to clean up your CMake file to an extent that the "install" target works (mine is here).
I may have not expressed myself correctly. I just wanted to compile and build executables from my project, then find a way to copy it on another machine without having to install all dependencies before running the app.
The solution I found (with the help of a more experienced developer) was as follows:
1- Get all dependencies using ldd
2- Copy dependencies in a directory dependencies
3- On the target environment, copy content of dependencies into /usr/local/lib/myapp/
4- On the target environment, goto /etc/ld.so.conf.d/
5- create the file myapp.conf with one line in it: /usr/local/lib/myapp
6- run ldconfig
Then, the executable I created on my development machine runs here smoothly!
Of course all the steps I described up there must be listed in a script for automation
I'm using ubuntu 18.04.
I want to modify and build a project and install it as a package. For example gstreamer1.5.
So I clone repo, modify code and use ./autogen.sh and make install in project folder. Why don't I see it in apt list then? Also there is no files in /usr/lib/x86_64-linux-gnu/gstreamer-1.5/.
The reason why I want it to behave as the original package is becase I want to build another project that uses it (kurento media server). So I just want to remove some plugins I don't need that use another packages as deps I cannot use.
apt list is from the Linux distribution. You custom made things won't appear there magically.
If you make install from your custom tree your libraries and plugins will land in /usr/local/lib/.. (note the local path). You may have some control over it by setting the prefix path. Just be careful you don't break you system by overwriting with broken libraries.
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
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.