-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem installing janetui on GNU/Linux #4
Comments
After adjusting a few things I was able to see The changes I made were to:
For For Various versions of things here were: This was on a Linux box. |
Ok. I cloned this repo onto my local machine. I checked that I had /usr/local/include/janet/janet.h present, then went into main.c and changed the include line to Then, as root, and from within my cloned ~/temp/janetui dir, I ran It errored out with:
I see that the libui directory is empty.
|
@uvtc Have you tried cloning this repository using the |
@uvtc I got a) These bindings use git submodule to embed a copy of libui, currently stuck on old commit from 2019. diff --git a/test.janet b/test.janet
index ac11bea..5378693 100755
--- a/test.janet
+++ b/test.janet
@@ -1,6 +1,6 @@
#!/usr/bin/env janet
-(import build/libjanetui :as ui)
+(import ./build/libjanetui :as ui)
(def menu (ui/menu "File")) |
I did:
and everything seemed to complete fine. Though I don't see where it was installed --- there's no janetui in /usr/local/lib/janet. And when I try to run the test file, it can't find janetui either:
The build directory appears to contain janetui:
|
@cody271 , thanks. When I change that one line to a relative import, the app runs! |
@sogaiu , thanks. The It looks like, when originally trying
maybe it did not recursively pull in libui? Where does |
@uvtc I don't know off the top of my head, but I looked at the output here for
That seems to suggest that jpm was fetching I don't tend to install janet things using system directories but rather under my home directory -- in my case the cloned libui ended up here:
FWIW, I don't think |
hi, i made some changes in my forks cmakelists.txt and now jpm install actually works: i can just import janetui now, please check out my fork https://github.com/kamisori/janetui its just the last commit really ^^ |
I gave it an attempt. I still get the header file path problem:
May be this has to do with my using a "non-system" Janet setup. |
well, caveat time: i can only install after calling jpm build twice... first time breaks because the shared object file that is emitted by cmake is missing, when jpm wants to build the native module at the start of the build process.... i dont know how to juggle the build process in a way so that cmake is called before attempting to build the native module shrug |
Regarding the header file problem pointed out here, I think this has to do with where cmake looks for headers in combination with a non-system install of janet. Adding the following to CMakeLists.txt: if(EXISTS "/home/user/.local/include/janet.h")
include_directories("/home/user/.local/include")
endif() fixes things for my local case. Far from optimal (and limited to non-Windows likely), but may be there's some other good way to get cmake to accomodate non-system installs of janet. |
I think the diff below is an improvement over the previous hack. The idea is to use jpm's knowledge of where diff --git a/CMakeLists.txt b/CMakeLists.txt
index dc788e8..53370ff 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -42,6 +42,10 @@ main.c
# Get the header ui.h
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/libui)
+if(MY_JANET_HEADER_PATH)
+ include_directories(${MY_JANET_HEADER_PATH})
+endif()
+
# Build libui as static library
set(BUILD_SHARED_LIBS OFF CACHE BOOL "")
add_subdirectory(libui)
@@ -54,4 +58,4 @@ target_link_libraries(${TARGET_NAME} libui glib-2.0 gtk-3 gdk-3)
add_library("${TARGET_NAME}STATIC" STATIC ${SOURCES})
target_link_libraries("${TARGET_NAME}STATIC" libui glib-2.0 gtk-3 gdk-3)
diff --git a/main.c b/main.c
index 83f5d17..f3fb08c 100644
--- a/main.c
+++ b/main.c
@@ -20,7 +20,7 @@
* IN THE SOFTWARE.
*/
-#include <janet/janet.h>
+#include <janet.h>
#include <string.h>
#include <stdlib.h>
diff --git a/project.janet b/project.janet
index 88dea5a..6a69842 100644
--- a/project.janet
+++ b/project.janet
@@ -6,12 +6,15 @@
(def o (os/which))
+(use jpm/config)
+
(rule "build/janetui.so" ["CMakeLists.txt"]
(do
+ (def option (string "-DMY_JANET_HEADER_PATH=" (dyn:headerpath)))
(assert
(and
(zero?
- (os/execute ["cmake" "-B" "build"] :p))
+ (os/execute ["cmake" "-B" "build" option] :p))
(zero?
(os/execute ["cmake" "--build" "build"] :p)) "--build build"))))
@@ -40,4 +43,4 @@
:name "uwudemo"
:entry "test.janet"
:install false) |
cmake should be able to pick up on environment vars, so something like this should work but//. if(DEFINED $ENV{JANET_HEADERPATH})
include_directories($ENV{JANET_HEADERPATH})
endif() but in my case it might be that this particular var has the same value as INCLUDE on my system so idk what coincidence made janetui "magically" compile here (apart from my commits of course :P) xD |
oh no... so as it is now, cmake builds libui AND the native module and then jpm builds the native module again... and i cant make jpm cleanly run one thing before another.... see my project.janet as of now.. its a little frustrating. otherwise i could just remove the cmakelists.txt and call cmake in libuis directory, just build that without the shared libs:
but how to chain it before jpm runs "build"? idk. add-dep seems to work, but somehow jpm starts to build main.c before the dependency is through... my hotfix was to call the cmake build process in the root of project.janet.... ugh... on second thought, dont look at it... 🤦 |
On my system,
If you did a default install of Janet on Windows, may be "it all just works" (TM). |
If this is the build being parallelized, possibly serializing via jpm's
May be using |
indeed it did, thank you for the help |
After
apt install libgtk-3-dev
, I triedIt gets through a lot of the process, but then ends with:
with no janetui installed.
This is with Janet 1.19.2 on Debian Testing. cmake version 3.22.1.
The text was updated successfully, but these errors were encountered: