I'm trying to port some stuff at work over to cmake, and something that we do with our Windows installers (which currently use Inno Setup) does not appear to have a corollary in cmake/cpack. We have development libraries that get installed based on environment variables at installation time. So, the include files go to something like "%DEV_INCLUDE_DIR%/include" and the library files themselves go to something like "%DEV_LIB_DIR%/lib", and the environment variables DEV_INCLUDE_DIR and DEV_LIB_DIR are in the environment on the box when the installer is run. So, what they were on the box that the installer was generated on is irrelevant.
However, cmake seems to want all of that configured at compile time. It uses the install target to generate the package target for cpack, and you use the install commands to add stuff to be installed with the installer. And it doesn't work right if I try and put environment variables in the path. If I try
install(DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/Include/" DESTINATION "%DEV_INCLUDE_DIR%/include")
then I end up with a %DEV_INCLUDE_DIR% folder in the CMAKE_INSTALL_PREFIX when the package is installed with the NSIS installer, which definitely isn't what I want. I want it to replace %DEV_INCLUDE_DIR% with the value of that environment variable at install time. And I can't find any way to do that. Does anyone know how to do that or if it's even possible?
Truth be told, I don't even what an install prefix in this case (everything gets installed based on the environment variables), but cmake seems to be built around the idea that there is one, and I was hoping that the install prefix would just be ignored (or worst case, create an empty directory) if every DESTINATION in the install commands was an absolute directory, but it's not treating the environment variables as either environment variables or absolute directories. And all of the ways that I can think to tell cmake to treat it as an environment variable (e.g. $ENV{DEV_INCLUDE_DIR}") would involve using the environment variable on the box that it's built on rather than the box that it's installed on. Is there any way to get cmake/cpack's install/package stuff to actually use the environment variables at installation time?
Related
I am getting the following error on Windows:
Cargo, the Rust package manager, is not installed or is not on PATH.
remote: This package requires Rust and Cargo to compile extensions.
I've installed Rust and cargo is in the path, but the problem persists. Does anybody know why this is happening?
Error message is the same as in this post.
Heroku's stack runs on Ubuntu. Cargo is required by pywinpty but that's a library required for communicating with Windows processes. You may need it for your local environment but you don't need it for Heroku. You should try removing pywinpty from your requirements.txt when you deploy to Heroku.
If you want a temporary solution
Open a command line prompt (cmd) and execute
path
that will show you the actual, current path. Inspect it to see whether the necessary directories are really absent. If they are, execute
path=%path%;directory you want to add;other directory you want to add
The path will be available in the command prompt for as long as it's open. If they are present, reboot the computer, the addition to the path may have been delayed after installation.
The permanent solution
For Win10 but I guess instructions are not very different for other flavors.
Open System properties, find Environment Variables. In the dialog that pops up you will see System Variables, among which you will see Path. Select it, click edit and add the directories you need via the New button. Close all popup boxes and reboot (always a good idea when Windows is stubborn ;-) )
I'm trying to pass an environment variable to an external project in my CMakeLists.txt without any success.
In this case, I have a dependency to mbedtls library which is downloaded and built in my cmake. In Linux this works as intended, however in a Windows environment, I need to pass a variable WINDOWS_BUILD=1 to the make environment.
I have tried to add a CONFIGURE_COMMAND to a batch file which sets this environment variable in the ExternalProject_Add(), however this does not work. If I manually go into the automatically downloaded mbedtls folder and write
$ make WINDOWS_BUILD=1
it works as intended, however I want to build everything from CMake environment. Any takes?
I develop across 3 different platforms, Windows, OS X and Ubuntu Linux.
I use Dropbox to synchronize my code between all 3 platforms.
The problem I have is compiled binaries on OS X and Linux get the same name, so binaries in my GOPATH are always overwriting each other. I don't have this problem with Windows because binaries always compile with a .exe extension.
Has anyone else experienced this problem, and if so, how did you get around it?
The solution is simple: only share the $GOPATH/src folder across your computers, there is really no need to share the complete $GOPATH as package objects ($GOPATH/pkg) and binaries ($GOPATH/bin) compiled to one platform have no real use on other platforms, and they are reproducible by a simple compilation.
This will also reduce the storage and bandwidth. If for some reason you would still need the compiled binaries for other platforms, the go tool has built-in support for cross compilation, e.g. GOOS=windows go build will simply produce you the Windows executable binary of the package whose folder you're in in any OS, placed in the current folder (you can also change the architecture with GOARCH).
Another option would be to put your code under a source control e.g. git (github.com), which also preserves history. The go tool also has support to easily get the source code from a git repository, e.g. go get -u github.com/youruser/yourpackage.
1- set GOBIN to separate path (just e.g. for OS X) and use
go install
Command go :
If the GOBIN environment variable is set, commands are installed to the
directory it names instead of DIR/bin. GOBIN must be an absolute path.
2- Also you may rename the output file:
go build [-o output] [-i] [build flags] [packages]
Like this:
go build -o newname
The -o flag, only allowed when compiling a single package, forces
build to write the resulting executable or object to the named output
file.
Also see: How do I use a Samba server location for GOPATH?
I have compiled OCaml from source on my mac (the host), and I have no problem. I have also cross-compiled OCaml on my mac for some target (different from the host) and in this case I have the following issues :
1) I can use directly (on the target) ocamlrun and ocamlyacc as they are "pure" binaries, without problem, as on the host. If I want to use other binaries from $INSTALL/bin ($INSTALL is the install directory of ocaml on the target) like ocamlopt, I have errors telling my that the path of ocamlrun is wrong. Indeed, if I open the ocamlopt binary with and hexadecimal editor, I see that it begins with a #!/not/target/but/host/path/to/ocamlrun where the path is the path to ocamlrun on the host (my mac) on which I configured the cross-build, not the path to its target version... Of course, if I replace this path by the one on the target, no need anymore to do ocamlrun ocamlopt, everything is ok. Same for all others binaries from $INSTALL/bin, ocamlrun and ocamlyacc put aside. (The last two do work directly, as I wrote above.) Is there a way to configure (on host) the ocaml cross-build so that the right path for ocamlrun on the target appears directly at beginning of binaries from $INSTALL/bin ?
2) I cannot compile code without needing to specify the $INSTALL/lib/ocaml dir through the -I flag. Is there a way to force this standard libraries path at the configure ? Or any ocaml "internal" environment variable dealing with it that I could edit to be sure that ocaml will look for libs in $INSTALL/lib/ocaml ? (I am quite pessimistic for an environment variable solution as on the host I only have two environment variables (at printenv) concerning ocaml and no one seems to deal with this kind of stuff, so that I don't see why it would go differently/better on the target...)
I'm working on windows 7 64bit system using clozure cl (version 1.8-r15286m) with quicklisp installed.
I need some freetype2 bindings for common lisp. (map characters to glyphs + kerning info)
I've tried to install "cl-freetype2" using
(ql:quickload "cl-freetype")
from 32bit clozure cl, and I've run into several problems.
"grovel.lisp" (located in quicklisp/software/cffi_0.11.1/grovel/grovel.lisp) assumes that I have gcc installed at "c:/msys/1.0/bin/gcc.exe" (I have mingw-gcc in path, but not there). Fixed by replacing "c:/msys/1.0/bin/gcc.exe" with "gcc" in "grovel.lisp".
When trying to compile cffi bindings for freetype2, same file does not include drive letters when passing include directories to compiler (i.e. instead of -i"d:/somedir" it passes -i"/somedir" to gcc`).
"grovel.lisp" tries to include unix include directories.
I cannot fix #2 myself.
I found this discussions, tried both listed patches, and neither of them worked. (first one breaks cffi, because ccl can't find neither "namestring-prefix" function nor "pathname-prefix" function), second one does not fix the problem.
What can I do in this situation?
I'd prefer to avoid fixing "groveller" myself, I simply need some bindings for freetype2.
Basically, I need to be able to
Load truetype font.
Map unicode char to glyph.
Get kerning information for pair of glyphs.
Load glyph bitmap.
Any ideas?
Figured it out.
Installing cl-freetype2 via quicklisp requires fully functional installation of MinGW.
Ensure that mingw-gmp is installed. (mingw-get install gmp)
Ensure that mingw/bin directory is within system path (right click on "My Computer"->Properties->Advanced->Environment Variables). Is Set. Should be something like "D:/development/MinGW/bin " (assuming MinGW is installed in "d:/development").
Locate "grovel.lisp" within your ccl installation, and replace ""c:/msys/1.0/bin/gcc.exe" with "gcc". You don't have to do that if gcc is installed at this location.
Launch mingw shell.
download unpack and install latest Freetype2 tarball using ".configure && make && make install", similarly to unix enviornment.
Locate freetype-6.dll copy it into freetype.dll and move freetype.dll into location within system path.
(Assuming that MinGW is installed in "d:/development/MinGW"), create CPATH user environment variable with following context: D:\development\MinGW\msys\1.0\local\include\freetype2;D:\development\MinGW\msys\1.0\local\include. That is - if you didn't specify "/usr" prefix during freetype2 compilation.
From within mingw shell, launch wx86cl and try (ql:quickload "cl-freetype2"). It should work properly.
If it still doesn't work, in all your root drives create directory junctions to directory in which mingw is installed. (i.e. "c:/development" linking to "d:/development", etc).
I must admit that this was much hassle, so I still think that it'll be a better idea to make a small dll that provides minimal set of functions I need while using freetype internally, then load this dll using cffi. This should be much easier.