I am totally new to Opal. I am just testing out how to use it by writing simple Ruby code in a local file, compiling it using opal -c test.rb > test.js, and then executing the resultant js file using node test.js. This is working fine when all of the code that I want is in test.rb. If, however, when test.rb has for the first line, require_relative 'other_file' and other_file.rb exists in the same directory with test.rb, then it fails when executed with node. I get an error message that begins like this:
/Users/huliax/projects/scratch/opaltest/test.js:5022
throw exception;
^
LoadError: can't find file: "other_file" in:
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/opal-0.11.0/opal
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/opal-0.11.0/stdlib
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/opal-0.11.0/lib
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/ast-2.3.0/lib
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/ast-2.3.0/lib
- /Users/huliax/.rvm/gems/ruby-2.5.0#car/gems/parser-2.3.3.1/lib
This suggests that to me that I should have no problem with require_relative. I am not getting any compile time errors. I have also tried compiling other_file.rb to js independently but that hasn't helped. I can only assume that I am misunderstanding things. What do I need to do in order to get this to work?
Ultimately, my goal is to try and use Opal to compile an entire ruby library/gem (which consists of quite a few files) to JavaScript.
Please use a relative path with require relative and include the extension, e.g.:
require_relative "./other_file.rb"
And then when compiling be sure to include the current dir or a common parent dir between the two files in the include paths, e.g.:
opal -I. test.rb -c > test.js
(tested on opal v0.11.0)
Related
Has anyone been able to compile fluoride bluetooth stack separately for an embedded linux device?
There is a guide at https://android.googlesource.com/platform/system/bt/+/181144a50114c824cfe3cdfd695c11a074673a5e/README.md, but following these instructions gn gen fails without getting the common-mk folder and modding some build files so there are no missing variables, folders etc.
I have been able to generate Ninja files, but when building, there are missing gtest and modp_b64 headers. After getting them from Google's source search, Ninja seems to be able to run a bit without errors, but ultimately fails with:
In file included from ../../third_party/libchrome/base/message_loop/message_loop.h:18:
../../third_party/libchrome/base/message_loop/message_loop_current.h:209:3: error: static_assert failed due to requirement 'std::is_same<MessagePumpForUI, MessagePumpLibevent>::value' "MessageLoopCurrentForUI::WatchFileDescriptor is not supported when MessagePumpForUI is not a MessagePumpLibevent."
static_assert(std::is_same<MessagePumpForUI, MessagePumpLibevent>::value,
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../third_party/libchrome/base/message_loop/message_loop_current.h:214:28: error: no type named 'Mode' in 'base::MessagePumpGlib'; did you mean 'MessagePumpLibevent::Mode'?
MessagePumpForUI::Mode mode,
^~~~~~~~~~~~~~~~~~~~~~
MessagePumpLibevent::Mode
../../third_party/libchrome/base/message_loop/watchable_io_message_pump_posix.h:55:8: note: 'MessagePumpLibevent::Mode' declared here
enum Mode {
^
In file included from ../../third_party/libchrome/base/run_loop.cc:10:
In file included from ../../third_party/libchrome/base/message_loop/message_loop.h:18:
../../third_party/libchrome/base/message_loop/message_loop_current.h:215:28: error: no type named 'FdWatchController' in 'base::MessagePumpGlib'; did you mean 'MessagePumpLibevent::FdWatchController'?
MessagePumpForUI::FdWatchController* controller,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MessagePumpLibevent::FdWatchController
../../third_party/libchrome/base/message_loop/message_pump_libevent.h:28:9: note: 'MessagePumpLibevent::FdWatchController' declared here
class FdWatchController : public FdWatchControllerInterface {
^
In file included from ../../third_party/libchrome/base/run_loop.cc:10:
In file included from ../../third_party/libchrome/base/message_loop/message_loop.h:18:
../../third_party/libchrome/base/message_loop/message_loop_current.h:216:28: error: no type named 'FdWatcher' in 'base::MessagePumpGlib'; did you mean 'MessagePumpLibevent::FdWatcher'?
MessagePumpForUI::FdWatcher* delegate);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
MessagePumpLibevent::FdWatcher
../../third_party/libchrome/base/message_loop/watchable_io_message_pump_posix.h:17:9: note: 'MessagePumpLibevent::FdWatcher' declared here
class FdWatcher {
^
4 errors generated.
All the errors and missing files are coming from third_party/libchrome
Any help would be much appreciated.
I followed instructions at https://cs.android.com/android/platform/superproject/+/master:system/bt/README.md
In addition to instructions there, I had to resolve issues in the build script manually. I was able to compile the bluetooth stack successfully in Ubuntu 21.04
Replace //bt with /home/udara/fluoride/bt in build files.
Used sed command. Change to your fluoride directory as appropriate.
for file in $(grep -r -l "//bt"); do sed -i 's/\/\/bt/\/home\/udara\/fluoride\/bt/g' $file; done
Copied common-mk symlink generated by bootstrap.py to the fluoride directory.
And replaced //common-mk with /home/udara/fluoride/common-mk.
for file in $(grep -r -l "//common-mk"); do sed -i 's/\/\/common-mk/\/home\/udara\/fluoride\/common-mk/g' $file; done
Installed few missing dependencies
sudo apt install llvm
sudo apt install libc++abi-dev
Copied /home/udara/fluoride/bt/output/out/Default/gen/ABS_PATH/home/udara/fluoride/bt/gd/dumpsys/bundler/bundler_generated.h to /home/udara/fluoride/bt/gd/dumpsys/
cp /home/udara/fluoride/bt/output/out/Default/gen/ABS_PATH/home/udara/fluoride/bt/gd/dumpsys/bundler/bundler_generated.h /home/udara/fluoride/bt/gd/dumpsys/
Created directory named output in the bt directory.
Set environment variables
# this is set by bootstrap.py
export STAGING_DIR=/home/udara/fluoride/staging
# you have to manually set this
export OUTPUT_DIR=/home/udara/fluoride/bt/output
Then compile the bluetooth stack with
./build.py --output ${OUTPUT_DIR} --platform-dir ${STAGING_DIR} --clang
Add the following lines to /etc/dbus-1/system.d/bluetooth.conf
<policy>
...
<allow own="org.chromium.bluetooth"/>
<allow own="org.chromium.bluetooth.Manager"/>
</policy>
Finally run fluoride with
cd /home/udara/fluoride/bt/output/debug
sudo ./btadapterd --hci=0 INIT_gd_hci=true
The reason the common-mk issues are coming up because between the instructions being written, and now, libchrome has added a BUILD.gn file - so it is being used, instead of the substitute one in build/secondary/third-party/libchrome as intended. To fix this part of the build, just delete third-party/libchrome/BUILD.gn - should prevent the need for a lot of build fiddling.
The second part is because of the configuration of libchrome. Once you remove the file mentioned, then you need to modify build/secondary/third-party/libchrome/BUILD.gn to add the following not just to the source_set (as is done in upstream) but also to libchrome_config for downstream users:
defines = [
"__ANDROID_HOST__=1",
]
This will affect the build config so it doesn't try to use glib.
My best work on getting this to build is here, though I haven't gotten it to work entirely. https://github.com/rpavlik/fluoride I did this mostly as an experiment, feel free to continue where I left off.
I am trying to build an xsreensaver module using the makefile. I downloaded the source from http://www.jwz.org/xscreensaver/, and read the hacking readme.
As my screensaver involves opengl and reading of images, I'm trying to compile the 'photopile' screensaver.
I've run the following
$ cd xscreensaver-5.29
$ cd hacks
$ cd glx
$ make photopile
After running I get the following output errors
cc photopile.c -o photopile
photopile.c:38:23: fatal error: xlockmore.h: No such file or directory compilation terminated.
make: *** [photopile] Error 1
The referenced file is in the "hacks" root folder rather than the "glx" folder. I realize it would be simple enough to just copy that needed file to "glx", but the "xlockmore.h" file is not the only file that its trying to find that is not in the current directory.
It is also looking for "yarandom.h" in the "../../utils" folder.
I'm assuming the makefile was made correctly, and that I am doing something wrong with regards to calling the
make photopile
option from within the "glx" folder.
I'm still learning makefiles and would rather not modify it (or the directory structure by copying header files) anymore than the directions say to.
Any advice?
I have a program that is built up of many C++ and Haskell files.
I compile all of the Haskell with -fhpc flag so that I may run coverage tests on it.
After compiling is finished, I run the program and several .tix files are generated.
The problem: I attempt to run hpc markup build/Server --srcdir=. for instance.
It will then generate some files, but fail prematurely:
Writing: file1.hs.html
Writing: file2.hs.html
Writing: file3.hs.html
hpc: can not find Main in ["./.hpc"]
The directory .hpc exists, and it does contain a file called Main.mix alongside other .mix files.
I've noticed some people reporting the same issues on IRC chat logs, but nowhere have I found a solution for this.
Does anyone have this experience with hpc?
Edit: How I compile
I have a fairly complicated compiling scheme.
I actually just wrote it down in another question.
I use a very specific package library which I specify explicitly by using --no-user-package-db and --package-db=/usr/local/ghc-7.6.3-200814.
That directory's listings is available here
I finally got it running today.
I changed my compilation to have no optimizations at all.
I ran my server from the base project directory by running ./build/Server ...
I generated a list of all my modules to be included using sed inside Make.
(My directory structure is the same as the module names.
For example, the filename haskell/Database/Module/Server/Server.lhs will become Database.Module.Server.Server.)
includify = $(foreach pkg,$(1), --include=$(pkg))
MODULES = $(shell find haskell -name "*.lhs" | sed -e "s/\.lhs\$$//g" | sed -e "s/^haskell\///g" | sed -e "s/\//\./g")
INCLUDES = $(call includify,$(MODULES))
and then created the target (inside Make again)
#echo "WRITING coverage/result.xml"
#hpc report Server srcdir=build $(INCLUDES) --xml-output > build/coverage/result.xml
#echo "WRITING coverage HTML FILES"
#hpc markup Server srcdir=build $(INCLUDES) --destdir=build/coverage
And this is how I solved my issues.
According to the comment in node.js file src/node.js, line 55, and this discussion thread about the topic (Standalone? - nodejs):
// To allow people to extend Node in different ways, this hook allows
// one to drop a file lib/_third_party_main.js into the build
// directory which will be executed instead of Node's normal loading.
So I figured I could do something like this:
git clone https://github.com/joyent/node \
&& cd ./node \
&& echo 'console.log("Hello, World!");' > lib/_third_party_main.js \
&& ./configure
&& make -j4
But the resulting executable at "./node" just runs the normal REPL loop (or main module if an argument is given) as though the "third party main" module wasn't detected. I was hoping the executable would instead print "Hello, World!" (per my custom main module) and exit so I could build a statically linked executable for simple distribution of a node-based application.
Any idea how to get this "standalone" build via "_third_party_main" working?
Didn't automatically compile in for me either. It's up to the build system to compile that JS file into the main executable, so it looks like it's not doing that automatically.
It works if I add 'lib/_third_party_main.js' to the node.gyp file's 'library_files' key, so maybe just stick with that?
I guess this would be a generic question on including libraries with existing makefiles within cmake; but here's my context -
I'm trying to include scintilla in another CMake project, and I have the following problem:
On Linux, scintilla has a makefile in (say) the ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk directory; if you run make in that directory (as usual), you get a ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/bin/scintilla.a file - which (I guess) is the static library.
Now, if I'd try to use cmake's ADD_LIBRARY, I'd have to manually specify the sources of scintilla within cmake - and I'd rather not mess with that, given I already have a makefile. So, I'd rather call the usual scintilla make - and then instruct CMAKE to somehow refer to the resulting scintilla.a. (I guess that this then would not ensure cross-platform compatibility - but note that currently cross-platform is not an issue for me; I'd just like to build scintilla as part of this project that already uses cmake, only within Linux)
So, I've tried a bit with this:
ADD_CUSTOM_COMMAND(
OUTPUT scintilla.a
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... but then, add_custom_command adds a "target with no output"; so I'm trying several approach to build upon that, all of which fail (errors given as comment):
ADD_CUSTOM_TARGET(scintilla STATIC DEPENDS scintilla.a) # Target "scintilla" of type UTILITY may not be linked into another target.
ADD_LIBRARY(scintilla STATIC DEPENDS scintilla.a) # Cannot find source file "DEPENDS".
ADD_LIBRARY(scintilla STATIC) # You have called ADD_LIBRARY for library scintilla without any source files.
ADD_DEPENDENCIES(scintilla scintilla.a)
I'm obviously quote a noob with cmake - so, is it possible at all to have cmake run a pre-existing makefile, and "capture" its output library file, such that other components of the cmake project can link against it?
Many thanks for any answers,
Cheers!
EDIT: possible duplicate: CMake: how do i depend on output from a custom target? - Stack Overflow - however, here the breakage seems to be due to the need to specifically have a library that the rest of the cmake project would recognize...
Another related: cmake - adding a custom command with the file name as a target - Stack Overflow; however, it specifically builds an executable from source files (which I wanted to avoid)..
You could also use imported targets and a custom target like this:
# set the output destination
set(SCINTILLA_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk/scintilla.a)
# create a custom target called build_scintilla that is part of ALL
# and will run each time you type make
add_custom_target(build_scintilla ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target")
# now create an imported static target
add_library(scintilla STATIC IMPORTED)
# Import target "scintilla" for configuration ""
set_property(TARGET scintilla APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
set_target_properties(scintilla PROPERTIES
IMPORTED_LOCATION_NOCONFIG "${SCINTILLA_LIBRARY}")
# now you can use scintilla as if it were a regular cmake built target in your project
add_dependencies(scintilla build_scintilla)
add_executable(foo foo.c)
target_link_libraries(foo scintilla)
# note, this will only work on linux/unix platforms, also it does building
# in the source tree which is also sort of bad style and keeps out of source
# builds from working.
OK, I think I have it somewhat; basically, in the CMakeLists.txt that build scintilla, I used this only:
ADD_CUSTOM_TARGET(
scintilla.a ALL
COMMAND ${CMAKE_MAKE_PROGRAM}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scintilla/gtk
COMMENT "Original scintilla makefile target" )
... and then, the slightly more complicated part, was to find the correct cmake file elsewhere in the project, where the ${PROJECT_NAME} was defined - so as to add a dependency:
ADD_DEPENDENCIES(${PROJECT_NAME} scintilla.a)
... and finally, the library needs to be linked.
Note that in the commands heretofore, the scintilla.a is merely a name/label/identifier/string (so it could be anything else, like scintilla--a or something); but for linking - the full path to the actual `scintilla.a file is needed (which in this project ends up in a variable ${SCINTILLA_LIBRARY}). In this project, the linking basically occurs through a form of a
list(APPEND PROJ_LIBRARIES ${SCINTILLA_LIBRARY} )
... and I don't really know how cmake handles the actual linking afterwards (but it seems to work)
For consistency, I tried to use ${SCINTILLA_LIBRARY} instead of scintilla.a as identifier in the ADD_CUSTOM_TARGET, but got error: "Target names may not contain a slash. Use ADD_CUSTOM_COMMAND to generate files". So probably this could be solved smarter/more correct with ADD_CUSTOM_COMMAND - however, I read that it "defines a new command that can be executed during the build process. The outputs named should be listed as source files in the target for which they are to be generated."... And by now I'm totally confused so as to what is a file, what is a label, and what is a target - so I think I'll leave at this (and not fix it if it ain't broken :) )
Well, it'd still be nice to know a more correct way to do this eventually,
Cheers!