I have a Lua program (written in Lua 5.1). I'm on Windows 7, trying to use srlua to convert a lua file into an executable. finally i have create an executable used
glue.exe srlua.exe myscript.lua gd.exe
when i click exe/bat to execute. it crashed . tips : no find lua51.dll in computer.
when i used cmd to execute . it work. even i only move gd.exe to other dir.
so, why ?
doesnot srlua create standalone exe without lua environment?
dir ls
error tips
You are mixing Lua environments: your directory structure shows Lua51.dll, but your error message references Lua5.1.dll, which you don't have (and those are two different files). Somehow you depend on a module that was compiled against Lua5.1.dll. You can figure out the dependency chain by using a dependency walker as it will show what DLLs are being loaded and from what locations. You can also run it in the "profile" mode, which will show where the error you see happens in the dependency chain, so you'll know what DLL or executable is at fault.
In Windows, an executable will only look in a few places for the .dll (in order):
1) Any dependency paths will be searched first. These you can set when you are creating the project (generally through the IDE).
2) The current directory that the executable is running from. For example, if gd.exe was in the folder myexe in C: drive, the directory C:\myexe would be checked.
3) The system directory. For Windows, it's something along the lines of C:\Windows\System32.
4) Anything additional paths, specified by the PATH environment variable.
So, if you moved your executable gd.exe from C:\myexe to C:\myexe2, you would either need to point to the .dll via dependencies/the PATH environment variable, or move all of the .dll files that you need to the new directory.
If command line works to run the program, but not the .exe itself, your command line has the PATH environment variable set. You can set it in the command line using setx path "%path%;c:\newpath" or use the the Control Panel -> System and Security -> System then clicking on Advance System Settings -> Environment Variables and under System Variables, look for the PATH key word.
Keeping the .dll files and executable in the directory (c:\myexe for example) and running the executable is a good way to make sure they work together and that all required .dll files are seen by your executable.
Source (even though it doesn't mention the PATH environment variable): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Related
Is there a way to tell SBT which (locally) installed JDK to use?
I am quite certain I could change PATH and JAVA_HOME but I'd rather not change those settings since they apply for the whole system (Windows in that case).
I am more looking for a command line parameter of some sort.
If you're looking to specify a JDK for running SBT (rather than a JDK to use for running your code and/or tests from within SBT), you can make use of the JAVA_HOMES environment variable, plus a .java-version file in your project.
This is described in SBT's sbt.bat file (typically installed to C:\Program Files (x86)\sbt\bin) as a "poor man's jenv", which isn't currently available on Windows.
(If you're looking for a similar solution for Linux or MacOS, you can either use jEnv, or specify the Java home directory via the -java-home SBT command line option—which also, sadly, isn't currently implemented on Windows.)
The JAVA_HOMES environment variable (not to be confused with JAVA_HOME) is used by SBT to identify a directory that contains one or more JDK installations. For example, if you're using AdoptOpenJDK's JDK distributions (recommended on Windows, if Oracle's new licensing restrictions are a problem for you), then this would typically be defined as C:\Program Files\AdoptOpenJDK.
Let's say that you have two such JDK installations in the JAVA_HOMES directory: one in a subdirectory named jdk-8.0.212.03-hotspot; another in the jdk-11.0.3.7-hotspot subdirectory. You can select which JDK you want to use, on a project-by-project basis, by creating a file called .java-version in the root directory of each SBT project. To use the JDK in the jdk-8.0.212.03-hotspot subdirectory, this file should then contain:
jdk-8.0.212.03-hotspot
When you run the sbt command, if you have JAVA_HOMES defined, SBT will look for a .java-version file in the project's root directory. If it finds it, it creates a local version of JAVA_HOME that is defined as JAVA_HOMES plus the last line of .java-version. It also adds this JAVA_HOME's bin directory to the path. (It also creates a JDK_HOME process-local environment variable with the same value.)
This should do what you want. Although it's not a command line-based solution, it doesn't adversely affect other users, and allows each SBT project to be configured individually. If you do not have permission to create a system-wide environment variable, you should still be able to create a user-specific JAVA_HOMES environment variable. Note that when using this solution, the JDK that SBT uses is then not necessarily the one identified by your system-wide (or user-specific) JAVA_HOME environment variable. (If you have not defined JAVA_HOMES, then SBT will expect you to have defined a valid JAVA_HOME variable.)
One word of caution: if you commit .java-version to source control, you must ensure that everyone defines a valid JAVA_HOMES environment variable, and has a JDK with the exact same name installed in that directory.
I'm starting to experiment with Go and I'm facing an issue that (I think) doesn't exist in languages that use a virtual machine.
I have a src/test/main.go file that references my templates inside src/test/views/ folder.
When I use go run main.go it runs but when do go install and then inside my bin folder run the executable (./test) I get an error:
views/edit.html: no such file or directory
So, how does Go compiles my project (file/folder structure related) and how to use paths in a way that allows me to use either go run and go install/executable?
If you specify a relative path in your code, as in views/edit.html it will also be looked up relative to the binary location. You need to either make the path absolute, or use some logic to determine where your templates will be located.
Another option would be to use https://github.com/jteeuwen/go-bindata or https://github.com/elazarl/go-bindata-assetfs that will save you the hassle.
I'm trying to port a *nix, CMake-based project to Windows. One header file needed by the main library is generated by a custom program, so the CMakeLists.txt file contains something like this:
add_executable(TableGenerator "TableGenerator.cpp")
target_link_libraries(TableGenerator ${LibFoo_LIBRARY})
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
An important detail is that TableGenerator uses the external shared library LibFoo. For example under Linux, everything works fine, because libfoo.so is installed in one of the system library directories like /usr/local/lib, or CMake even sets the rpath attribute in the executable, saying where exactly to find the library.
On Windows, however, these kind of libraries are usually not installed into the system but are rather just extracted or compiled into some arbitrary directory in or near the build tree. In order for TableGenerator to run, the foo.dll would need to be available in or copied to one of the Dynamic-Link Library Search Order paths (say %WINDIR%\System32 or the build output directory for TableGenerator), which is not desirable.
How can I set the PATH environment variable for the custom command, i.e. to be used not during the CMake run but during the actual custom build step runtime?
While still doing my research in order to ask the question properly, I have found three solutions. Considering how hard it was to find this information, I decided to post the question and answer here anyway.
1. Using global variable CMAKE_MSVCIDE_RUN_PATH
There is a special variable dedicated to solving this exact problem – CMAKE_MSVCIDE_RUN_PATH. If set, it results in a line like this being added to the custom build step script:
set PATH=<CMAKE_MSVCIDE_RUN_PATH>;%PATH%
So all that's needed then is something like this at a good place:
set(CMAKE_MSVCIDE_RUN_PATH ${LibFoo_RUNTIME_LIBRARY_DIRS})
I have originally noticed this variable only in CMake sources, because it used to be undocumented until CMake 3.10. So you might not be able to find it in documentation for older versions of CMake, but don't worry, it's been supported since 2006.
Advantages:
▪ Can be enabled at one central place
▪ No change at all in any of the add_custom_command() commands elsewhere is needed
▪ Only the path itself is set, no batch commands need to be written explicitly
▪ The obvious choice with clear name and intent
Disadvantages:
▪ Global for the whole CMake project and all custom commands
▪ Works with the "Visual Studio 9 2008" and above generators only
2. Setting the PATH explicitly using two COMMAND parameters
The script being generated for the custom build step in Visual Studio contains some prologue, then the commands themselves and then some epilogue. Wouldn't it be possible to simply add set PATH=... before the real command through another COMMAND parameter?
The documentation for add_custom_command() says:
COMMAND
Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script.
So no, that's not guaranteed to be possible. But the Visual Studio project generator actually does it like this, i.e. the individual commands are just appended one after another, so the following does the job:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND set "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
Advantages:
▪ The PATH can be changed for each custom command explicitly
Disadvantages:
▪ Relies on an undocumented behavior of the generator
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
3. Using file(GENERATE ...) to create a custom script
The documentation for add_custom_command() quoted above continues:
To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.
This is a bit messy because of the additional temporary files and commands:
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd"
CONTENT "set PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%
%1 ${CMAKE_CURRENT_BINARY_DIR}/Table.h")
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd" "$<TARGET_FILE:TableGenerator>"
DEPENDS TableGenerator)
Notice the awkward way of sending the path to the executable as an argument. This is necessary because the script is writen once, but TableGenerator might be in different locations for different configurations (debug and release). If the generator expression was used directly in the content, a CMake error would be printed and the project would not build correctly for all but one configuration.
Advantages:
▪ The PATH can be changed for each custom command explicitly
▪ A fully documented and recommended solution
Disadvantages:
▪ Very noisy in the CMakefiles
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
4. Launch the custom command through CMake wrapper
See the other answer below contributed by Dvir Yitzchaki.
I had personally settled on the solution #1 because it was clean and simple, even before it got properly documented and supported by CMake in version 3.10. It should be the best way forward for you as well, unless you need to do something even more special.
There is another way besides what Yirkha wrote and that is to run the executable through cmake and use cmake's -E option to set the environment.
So in your case it will be:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND ${CMAKE_COMMAND} -E env "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS}" $<TARGET_FILE:TableGenerator> "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
See http://www.cmake.org/pipermail/cmake/2006-March/008522.html for details.
I'm using Maven and IzPack. I'm looking for a way to put a file into the directory of the installer file. In the install.xml I've got a file tag set with a targetdir of "." but that will only work if the installer is executed from that directory. If executed from a different directory, the file is put in the current working directory of the user instead.
Having checked IzPack documentation, there's a built-in variable for $INSTALL_PATH, but I need the path of the installer. There's no way to predict where this installer will be when executed so specifying a pre-set directory won't work. Trying to specify the local directory via Maven just gives the path to the POM.
Is there an undocumented variable that would do the job or something else I've overlooked?
I am trying to setup my TFS2010 Build and I want to access the files that are downloaded via the "Version control path to custom assemblies".
From what I can tell those files are downloaded to:
C:\User\<Build User>\AppData\Local\BuildAgent\<Built Agent Number>
I can directly access that folder via the above path, but it would be nice if there was an environment variable (or something I can use in the build) to access that folder indirectly.
Or... Is there a better way to get at these files? (I am putting a version file in there to be downloaded every time the build is run).
You can use %LOCALAPPDATA% environment variable. It expands to
RootDrive:\User\LoggedInUser\AppData\Local
Example: %LOCALAPPDATA%\BuildAgent
Note that %APPDATA% will expand to
RootDrive:\User\LoggedInUser\AppData\Roaming