I am working on a free software project: https://github.com/ccr/ccr
In this project I am building some shared-object libraries which are actually plugins for HDF5.
I don't want to install these libraries in /usr/local/lib. I want to install them in a special HDF5 plugin directory.
Here's what I have now:
AM_CPPFLAGS = -I$(HDF5_ROOT)/include -I$(BZ2_ROOT)/include
plugindir = /usr/local/hdf5/lib/plugin
# The libh5bz2 library for plugin module.
# Build it as shared library.
lib_LTLIBRARIES = libh5bz2.la
libh5bz2_la_SOURCES = H5Zbzip2.c
LDFLAGS = -L$(BZ2_ROOT)/lib
How do I get my library installed in plugindir?
the prefix (lib_) determines the installation path ($libdir).
You can setup your own prefix:
plugindir = ${prefix}/hdf5/lib/plugin
plugin_LTLIBRARIES = libh5bz2.la
sidenote: don't hardcode the full path in your Makefile. instead use the predefined variables. e.g. instead of /usr/local/hdf5/lib/plugin use something like ${prefix}/hdf5/lib/plugin, to allow users to easily change the actual installation path..
Define the variable 'libdir' to a string which is a path.
The variable declares (to automake and libtool) where to install the library.
If not defined, the library installs to a conventional place.
# install into private dir "lib" near other plugin executables
libdir = $(plugindir)/lib
Aside: as you hardcoded the definition of plugindir, you might be installing to a weird place.
When you use ${prefix}
you might find it installs to a subdirectory of the conventional place:
plugindir = $(prefix)/hdf5/plugin/lib
then that might for example install to /usr/local/lib/hdf5/plugin/lib which is more conventional?
Also, you might need to set rpath on any executables or libraries that reference your library.
Related
When writing luarocks install gumbo
In the location/directory of my luarocks file in cmd, I am getting the following error
Warning: Could not find Lua 5.3 in PATH.
Modules may not install with the correct configurations. You may want to specify the path prefix to your build of Lua 5.3 using --lua-dir
Installing https://luarocks.org/gumbo-0.5-1.src.rock
Error: Failed finding Lua library. You may need to configure LUA_LIBDIR.
I've added lua53.exe to the same directory, and added the file both to my user variables and system variables in control panel.
Not sure if worth mentioning, but when running lua53.exe and trying to use luarocks install gumbo from there,
the lua53 cmd-like window responds with stdin:1: syntax error near 'install'
I was hoping to do some web scraping with lua, and later on building a World of Warcraft addon that utilizes gumbo to show certain helpful information within the WoW client, but I can't seem to even get the most basic stuff to work...
Setting up LuaRocks on Windows is annoying and I'm not familiar with it myself. If you added both the LuaRocks and Lua 5.3 Windows binaries (Executables and Includes) to your Path system variable:
luarocks path prints the commands for setting up the LUA_PATH and LUA_CPATH system variables.
The config.lua file tells you what your variables.LUA_LIBDIR value is. You can check it with luarocks config. For me that file would be in:
C:/Users/Ketho/AppData/Roaming/luarocks/config-5.3.lua
otherwise you can create an empty file there and put in this line to point it to wherever your Lua folder is:
variables.LUA_LIBDIR = "C:/lua-5.3.5_Win32_bin"
variables.LUA_INCDIR = "C:/lua-5.3.5_Win32_bin/include"
As for using gumbo to show information within WoW, the addon environment is sandboxed. Unless you meant you just want to get the data to hardcode into your addon.
So I've installed Nix on Arch linux and I'm able to run nix-env -i example, however how can I define a Nix configuration?
As I don't have any /nixos/configuration.nix file present.
Is this possible?
My goal here is to be able to define a configuration which I could then use something like nixos-rebuild switch to install and provision all the software.
I use NixOS, but I use /etc/nixos/configuration.nix to describe my system; I keep it fairly minimal and prefer not to install "user" software by editing configuration.nix.
So what I do instead is use my ~/.nixpkgs/config.nix (which I believe you also have an equivalent of even in a non-NixOS nix install? I've never actually used nix separately).
The basic structure I use is this:
{
packageOverrides = nixpkgs: with nixpkgs; rec {
mine = with pkgs; buildEnv {
name = "mine";
paths = [
# your packages here
];
};
};
}
buildEnv is a convenience function from nix that makes an "environment" package out of a bunch of others; installing the package mine depends on (and so installs) all of the things listed in paths, and also makes sure they get included in PATH and things like that.
Then I just use nix-env -riA nixos.mine to deploy changes I've made to my environment description (or to rebuild my environment following channel updates). The -r tells it to remove everything else other than mine from the new generation of my profile, which means I can (ab?)use nix-env -i some-package as a way of "temporarily" installing some-package, and if I don't decide I like it enough to actually record it in my config.nix it'll just get removed anyway next time I deploy.
You can certainly create your own configuration. For example, you can do something like this:
let
pkgs = import <nixpkgs> {};
in
{
packages = [
pkgs.vim
pkgs.gimp
];
}
That would produce a set containing an attribute called packages, containing a list of Nix packages. But, you'd need to develop a tool to build environments from this, which is part of what nix-env does. For example, the tool can use nix-env to determine what is already installed, compare that to the selected packages in the configuration, and then install/uninstall packages accordingly.
You don't have a /etc/nixos/configuration.nix because that's NixOS-specific. So while you can do as you asked, you'd have to roll your own solution.
Not sure if this belongs on here or SuperUser, but here goes:
I have Homebrew installed in my $HOME/opt/homebrew dir (I'm pretty religious about isolation for user accounts - yes, I'm one of THOSE people). In any case, Homebrew doesn't install to /usr/local/. It works fine because I added Homebrew to the head of my personal path in .bashrc.
I'm now using autoconf. I'm a C newb. I have a configure.ac that checks for Apache Portable Runtime. It does the --install to generate a ./configure just fine. When I run ./configure, it doesn't find it - probably because it's not looking where Homebrew installed it.
I assume I have to provide arguments to the ./configure script setting the includedir and libdir. But it doesn't work. What is the right way to link to these Homebrew libs?
For posterity:
In configure.ac, I use the PKG_CHECK_MODULES macro. This assumes, of course, that you have pkg-check installed, which I do via Homebrew.
PKG_CHECK_MODULES(GLIB2, glib-2.0, [], [AC_MSG_FAILURE([glib-2.0 is not installed])])
The macro above sets a group of variables for use in the autoconf and automake files prefixed with GLIB2.
I use this in the Makefile.am thus:
bin_PROGRAMS = <myprogram>
<myprogram>_SOURCES = \
main.c
<myprogram>_CFLAGS = ${GLIB2_CFLAGS}
<myprogram>_LDADD = ${LIBS} ${GLIB2_LIBS}
It's really rather straightforward if you use pkg-config. You can even package your own libs and install them for use that way, linking them in place with Homebrew.
In NodeJS/NPM, you can create a package.json and run npm install to install all your dependencies in a folder within your project: ./node_modules. (A project can be an app or another module/package.)
Ruby also has a "bundler" system (using a .bundle file) that keeps track of gems specific to a dir (ie project).
Does LuaRocks have similar conventions? Or is it recommeneded to install everything to /usr or $HOME?
So far I've been able to get similiar functionality, but I have to create a custom LuaRocks config file and specify --tree=my_local_lua_rocks_dir every time I want to install a rock. Granted, I can always create a bash script. The point is that it seems I'm going against a convention.
It is possible to install rocks into a directory under the current directory, using the --tree flag:
luarocks install --tree ./lua_modules lpeg
And then you have to configure your package.path and package.cpath variables in Lua (settable via LUA_PATH and LUA_CPATH environment variables) so it finds the modules installed inside it. There are several ways to do this conveniently: this tutorial explains how to do it, with more examples.
Instead of using Vert, I've decided to just edit the LuaRocks config file:
In /etc/luarocks/config.lua :
rocks_servers = {
[[http://rocks.moonscript.org/]],
[[http://luarocks.org/repositories/rocks]]
}
rocks_trees = {
[[/usr/local]],
[[./my_dir]]
}
./my_dir is relative to the pwd you're in, not to the location of the config file. Of course, change my_dir to whatever you want.
"The order of the rock_trees matters: When installing rocks, LuaRocks tries to pick a location to store the rock starting from the bottom of the list; when loading rocks in runtime, LuaRocks scans from the top of the list." From: http://luarocks.org/en/Config_file_format
Then in your .bashrc:
eval `luarocks path`
export PATH=$PATH:my_dir/bin
However, for certain commands you now have to specify the tree or it will give you a confusing error:
luarocks make --tree=my_dir
I've been frustrated by the the CMake-CPack for almost one week.
The bad thing is the CMake-CPack online documentation does not document this part well.
After googling, I found this variables to use:
CPACK_PACKAGING_PREFIX # NOT documented
CMAKE_INSTALL_PREFIX # Documented, but the behavior seems weird
CPACK_INSTALL_PREFIX # NOT documented
CPACK_PACKAGE_INSTALL_DIRECTORY # Documented, but this variable does NOT work as the online document described
CPACK_PACKAGING_INSTALL_PREFIX # NOT documented
What I am trying to do is: package a Debian package using fakeroot make package, when the package is installed by sudo dpkg -i MyProgramPackageName, install it to /usr/local, with a subdirectory MyProgramPackageName. That is, all files should be installed under /usr/local/MyProgramPackageName-V.1.2.3.
I've been trying (CMake 2.8.3 and CMake 2.8.5) to tune these variables. I tried so many combinations, but failed.
The only way succeeded is:
Set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/MyProgramPackageName-V.1.2.3)
But this variable is NOT even documented, and the behavior cannot be guaranteed. If you are confused with my question, please advise me when to use CPACK_PACKAGE_INSTALL_DIRECTORY? because the documentation description about this variable is really attractive, and it is really what I want, but I just could not make it working.
Please advise me.
Peter
I didn't find any documentation to support this, but I did find some bug reports and email archives that seem to suggest that the following is what you should be doing:
set(CPACK_SET_DESTDIR true)
set(CPACK_INSTALL_PREFIX /opt/MySuperAwesomePrefix-v.1.2.3)
If CPACK_INSTALL_PREFIX is not set, it will default to CMAKE_INSTALL_PREFIX. Now relative paths from install(... DESTINATION dest) will end up as CPACK_INSTALL_PREFIX/dest inside your package file. This worked when I tried to generate a deb file.
The paths used by the CPACK are taken from the INSTALL directives in your CMakeLists.txt files. This allows the result package to mirror what a 'make install' would do. This keeps the CPACK configuration to a minimum.
So, from an example CMakeLists.txt file:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin)
This will install to /usr/bin or /usr/local/bin. If you wanted to place it in a subdirectory you could do it here:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin/myappdir)
Or entirely different directory:
INSTALL(TARGETS ${APPLICATION} DESTINATION /opt/foo/bar)