Part of my build process is to create a tar file of an input directory, located at src/bundle/bundle. In src/bundle/SConscript:
Import('*')
bundleDir = Dir("bundle")
jsontar = Command("bundle.tar", bundleDir,
"/home/dbender/bin/mkvgconf $SOURCE $TARGET")
in my SConstruct:
SConscript(Split('src/bundle/SConscript'),
exports='bin_env lib_env', build_dir='tmp/bundle')
When attempting to build:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
/home/dbender/bin/mkvgconf tmp/bundle/bundle tmp/bundle/bundle.tar
Input directory tmp/bundle/bundle not found!
scons: *** [tmp/bundle/bundle.tar] Error 1
scons: building terminated because of errors.
Clearly scons is not copying the src/bundle/bundle to tmp/bundle/bundle, but I am stumped as to why.
Footnotes:
Using absolute pathname for mkvgconf is bad practice but just intermediate until I have this problem solved.
SCons doesn't know anything about the contents of your input src/bundle/bundle - only the program mkvgconf knows what it does with that directory.
One solution is to add an explicit dependency in the SConscript:
import os
Depends('bundle.tar', Glob(str(bundleDir) + os.path.sep + '*'))
That also means that when you update the contents of the bundle directory, the mkvgconf script will be rerun.
PS. you might want to change the build_dir argument name to variant_dir, as the former is deprecated in favor of the latter in recent SCons releases.
Related
I want to specify a ASAN suppression file in .bazelrc. And the suppression file is located in workspace directory. I tried as following:
build:debug --action_env=LSAN_OPTIONS=suppressions=${workspace}/asan_leaks.supp
and
build:debug --action_env=LSAN_OPTIONS=suppressions=%workspace%/asan_leaks.supp
But what I got is:
AddressSanitizer: failed to read suppressions file
'/projects/mytest/bazel-output/execroot/mytest/bazel-out/aarch64-dbg/bin/mytest/${workspace}/asan_leaks.supp'
and
AddressSanitizer: failed to read suppressions file
'/projects/mytest/bazel-output/execroot/mytest/bazel-out/aarch64-dbg/bin/mytest/%workspace%/asan_leaks.supp'
It works if I hardcoded an absolute path, so I try to get the absolute path of workspace. Any suggestions are welcome, thanks.
Just update my workaround in case that somebody encouter similar issue:
Hardcode the suppression file with absolute path as following:
build:debug --action_env=suppressions=/tmp/asan_leaks.supp
Specify workspace_status_command relative to workspace directory
build --workspace_status_command=./bazel/cmd.sh
Make soft link to the suppression file in cmd.sh
bazel_dir=$(dirname -- "$(readlink -f $0;)")
ln -sf ${bazel_dir}/asan_leaks.supp /tmp/asan_leaks.supp
I follow https://www.tensorflow.org/xla/tfcompile, and fail at step 2.
What's wrong?
cschen
~/git/tensorflow$ bazel build --config=opt //t1:test_graph_tfmatmul
... INFO: Found applicable config definition build:download_clang in
file /home/cschen/git/tensorflow/.bazelrc:
--crosstool_top=#local_config_download_clang//:toolchain --define=using_clang=true --action_env TF_DOWNLOAD_CLANG=1 INFO: Found applicable config definition build:opt in file
/home/cschen/git/tensorflow/.tf_configure.bazelrc:
--copt=-march=native --copt=-Wno-sign-compare --host_copt=-march=native --define with_default_optimizations=true INFO: Build option --cpu has changed, discarding analysis cache.
ERROR: Analysis of target '//t1:test_graph_tfmatmul' failed; build
aborted: no such package 'tools/target_cpu': BUILD file not found on
package path ...
I copy to t1/BUILD from step 2 as follows,
~/git/tensorflow$ cat t1/BUILD
load("//tensorflow/compiler/aot:tfcompile.bzl", "tf_library") ...
The expected result is to generate header file test_graph_tfmatmul.h.
I don't know which version you are using, but on TF1.14, if you git grep tools/target_cpu, you will see one result in the file tensorflow/compiler/aot/tfcompile.bzl.
In the directory tools, there is nothing reminiscent of target_cpu, so I think it must be a bug with the tfcompile.bzl. The problem disappears for me when I comment out the line referencing tools/target_cpu.
I installed nodejs and hope to add bin directory for scons:
import os
env=Environment()
env.PrependENVPath('PATH','/home/my/node/bin')
print "PATH is", env.subst('$PATH')
Running scons, it prints:
PATH is
Well no value is printed. Why is that?
Change to the following to see the results of your PrependEnvPath
import os
env=Environment()
env.PrependENVPath('PATH','/home/my/node/bin')
print("PATH is", env['ENV']['$PATH'])
Yields:
$ scons.py
scons: Reading SConscript files ...
PATH is:/home/my/node/bin:/opt/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
I'm attempting to create a Homebrew formula for gtk-mac-integration. Running make in bindings/python/gtkosx_application fails:
/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't open file '/usr/local/Cellar/gtk-mac-integration/2.0.7/share/pygobject/2.0/codegen/h2def.py': [Errno 2] No such file or directory
make[3]: *** [gtkosx_application.defs] Error 2
This is because the Makefile tries to find the h2def.py file in the wrong location:
gtkosx_application.defs: $(headers)
$(PYTHON) $(datadir)/pygobject/2.0/codegen/h2def.py $(headers) > $#
It is clear to me why this is failing: $(datadir) points to the share directory of the package that is to be installed (gkt-mac-integration). Because Homebrew installs all packages into their own prefix (/usr/local/Cellar/...), it is not the same for gtk-mac-integration and pygobject.
I know it is possible to find out where the pygobject data directory is located using
pkg-config --variable=datadir pygobject-2.0
I don't suppose the correct fix is to replace datadir in the Makefile with the string above? How should I adjust configure.ac and Makefile.am to make this work properly?
Yeah, that sounds like a bug in the build system.
You can use the inreplace facility to patch this up. Insert this after def install:
inreplace %w[bindings/python/gtkmacintegration/Makefile.am
bindings/python/gtkmacintegration/Makefile.in
bindings/python/gtkosx_application/Makefile.am
bindings/python/gtkosx_application/Makefile.in],
'$(datadir)/pygobject', |
%x[pkg-config --variable=datadir pygobject-2.0].chomp + '/pygobject'
(I tried this out. The formula builds after that.)
You should report this upstream. They should change their build system to sort this out in their configure script.
I downloaded the source of LuaJIT and compiled it with msvc120.dll (VS 2013 x64). When I run it from the command line I have no problems executing some basic lua. Now the LuaJIT installation guide mentions moving luajit.exe and lua51.dll into their own folder. From there it says to create a lua folder and under that a jit folder with the contents of src/jit moved underneath the newly created jit folder.
From my understanding my folder should look like and contain:
luajit.exe
lua51.dll
/lua
/jit
bc.lua
[rest of jit files]
vmdef.lua
Is this correct or am I missing files?
Now after I built my luajit I tried to wire it up into my luarocks to act as my interpreter using
install.bat /LUA C:\LuaJIT\2.0.3\[folder with above content]
However this cannot find the header files. I then copied over what are the header files into the folder above and that wires it up, but I can never actually get anything to compile when pointed over to LuaJIT. Edit: The error I get is the following,
C:\LuaJIT\2.0.3\bin\lua51.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D0
Error: Failed installing dependency: https://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock - Build error: Failed compiling module lfs.dll
Is the correct way to handle this to simply point to my lua binaries and from there leverage LuaJIT to run my files or am I doing something wrong with wiring up LuaJIT and luarocks? The former seems to work for the most part, since I only ran into one library compilation issue, lua-cjson.
I've run on exactly the same problem, but they've found a solution right here:
https://github.com/keplerproject/luafilesystem/issues/22
I knew that for "linking DLLs statically" there is a so-called "export" .lib file, which is passed to the linker (and not the DLL itself).
So, for example, when compiling, LuaRocks was doing this:
cl /nologo /MD /O2 -c -Fosrc/mime.obj -ID:/LuaJIT-2.0.4/include/ src/mime.c -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG -DNDEBUG -DLUASOCKET_API=__declspec(dllexport) -DMIME_API=__declspec(dllexport) mime.c
link -dll -def:core.def -out:mime/core.dll D:/LuaJIT-2.0.4/bin/lua51.dll src/mime.obj
My LuaJIT was compiled from source in D:\LuaJIT-2.0.4\src, but I made two folders myself: D:\LuaJIT-2.0.4\include with all *.h files copied from src and D:\LuaJIT-2.0.4\bin with luajit.exe, lua51.dll, and then later lua51.exp and lua51.lib. Still same error, but this was the right track.
Fix
Now, check where your LuaRocks configs are:
luarocks.bat help
Scroll down to a section like:
CONFIGURATION
Lua version: 5.1
Configuration files:
System: D:/luarocks/config-5.1.lua (ok)
User : (... snip ...)
Edit the System configuration file, specifically see the part:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.dll'
}
Here! LUALIB should be the .lib file. If your export lib is alongside the DLL, you just need to change to:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.lib' -- here!
}
Verification
And now:
luarocks.bat install luasocket
(...)
link -dll -def:core.def -out:socket/core.dll D:/LuaJIT-2.0.4/bin/lua51.lib src/luasocket.obj (...)
(...)
luasocket 3.0rc1-2 is now built and installed in D:\luarocks\systree (license: MIT)
Note the first argument passed to the linker.