Skip to content
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

Open
uvtc opened this issue Jan 24, 2022 · 18 comments
Open

Problem installing janetui on GNU/Linux #4

uvtc opened this issue Jan 24, 2022 · 18 comments

Comments

@uvtc
Copy link

uvtc commented Jan 24, 2022

After apt install libgtk-3-dev, I tried

jpm install https://github.com/janet-lang/janetui

It gets through a lot of the process, but then ends with:

...snip...
[ 91%] Building C object libui/CMakeFiles/libui.dir/unix/text.c.o
[ 93%] Building C object libui/CMakeFiles/libui.dir/unix/util.c.o
[ 95%] Building C object libui/CMakeFiles/libui.dir/unix/window.c.o
[ 96%] Linking C static library out/libui.a
[ 96%] Built target libui
[ 98%] Building C object CMakeFiles/janetui.dir/main.c.o
...snip some warnings...
[100%] Linking C shared module libjanetui.so
[100%] Built target janetui
error: target "CMakeLists.txt" does not exist and no rule exists to build it
  in errorf [boot.janet] (tailcall) on line 165, column 3
  in utd1 [/usr/local/lib/janet/jpm/rules.janet] on line 76, column 31
  in visit [/usr/local/lib/janet/jpm/rules.janet] on line 85, column 12
  in visit [/usr/local/lib/janet/jpm/rules.janet] on line 84, column 7
  in visit [/usr/local/lib/janet/jpm/rules.janet] on line 84, column 7
  in visit [/usr/local/lib/janet/jpm/rules.janet] on line 84, column 7
  in build-rules [/usr/local/lib/janet/jpm/rules.janet] on line 93, column 19
  in <anonymous> [/usr/local/lib/janet/jpm/pm.janet] on line 212, column 9
  in <anonymous> [/usr/local/lib/janet/jpm/pm.janet] on line 198, column 5
  in bundle-install [/usr/local/lib/janet/jpm/pm.janet] on line 196, column 3
  in install [/usr/local/lib/janet/jpm/commands.janet] (tailcall) on line 105, column 20
  in _thunk [/usr/local/bin/jpm] (tailcall) on line -1, column -1
  in cli-main [boot.janet] on line 3666, column 17

with no janetui installed.

This is with Janet 1.19.2 on Debian Testing. cmake version 3.22.1.

@sogaiu
Copy link

sogaiu commented Jan 24, 2022

After adjusting a few things I was able to see test.janet running.

The changes I made were to:

  • the header file path in main.c
  • the import file in test.janet

For main.c #include <janet/janet.h> wasn't working so as a quick-hack I put an absolute path to an appropriate looking janet.h.

For test.janet I tweaked build/... to be ./build/....

Various versions of things here were:

This was on a Linux box.

@uvtc
Copy link
Author

uvtc commented Jan 30, 2022

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 #include "/usr/local/include/janet/janet.h"

Then, as root, and from within my cloned ~/temp/janetui dir, I ran jpm install.

It errored out with:

/home/john/temp/janetui# jpm install
generating /usr/local/lib/janet/.manifests/janetui.jdn...
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:43 (add_subdirectory):
  The source directory

    /home/john/temp/janetui/libui

  does not contain a CMakeLists.txt file.


-- Configuring incomplete, errors occurred!
See also "/home/john/temp/janetui/build/CMakeFiles/CMakeOutput.log".
make: *** No targets specified and no makefile found.  Stop.

I see that the libui directory is empty.

/home/john/temp/janetui# tree
.
├── build
│   ├── CMakeCache.txt
│   ├── CMakeFiles
│   │   ├── 3.22.1
│   │   │   ├── CMakeCCompiler.cmake
│   │   │   ├── CMakeCXXCompiler.cmake
│   │   │   ├── CMakeDetermineCompilerABI_C.bin
│   │   │   ├── CMakeDetermineCompilerABI_CXX.bin
│   │   │   ├── CMakeSystem.cmake
│   │   │   ├── CompilerIdC
│   │   │   │   ├── a.out
│   │   │   │   ├── CMakeCCompilerId.c
│   │   │   │   └── tmp
│   │   │   └── CompilerIdCXX
│   │   │       ├── a.out
│   │   │       ├── CMakeCXXCompilerId.cpp
│   │   │       └── tmp
│   │   ├── cmake.check_cache
│   │   ├── CMakeOutput.log
│   │   └── CMakeTmp
│   └── libui
├── CMakeLists.txt
├── libui
├── main.c
├── project.janet
├── README.md
└── test.janet

@sogaiu
Copy link

sogaiu commented Jan 30, 2022

@uvtc Have you tried cloning this repository using the --recursive option?

@cody271
Copy link

cody271 commented Feb 2, 2022

@uvtc I got test.janet working! Few issues tho:

a) These bindings use git submodule to embed a copy of libui, currently stuck on old commit from 2019.
b) jpm config seems very out of date? Assumes libui uses CMake as well, doesn't build with Meson.
c) I had to use a relative import:

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"))

test.janet

@uvtc
Copy link
Author

uvtc commented Feb 2, 2022

I did:

$ cd ~/temp
$ git clone --recursive https://github.com/janet-lang/janetui.git
$ su -
# cd ~john/temp/janetui
# jpm install
{... snip ...}
[100%] Linking C shared module libjanetui.so
[100%] Built target janetui
Installed as 'janetui'.

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:

~/temp/janetui$ ./test.janet 
error: could not find module build/libjanetui:
    /usr/local/lib/janet/build/libjanetui.jimage
    /usr/local/lib/janet/build/libjanetui.janet
    /usr/local/lib/janet/build/libjanetui/init.janet
    /usr/local/lib/janet/build/libjanetui.so
  in require-1 [boot.janet] on line 2700, column 20
  in import* [boot.janet] on line 2739, column 15
  in _thunk [./test.janet] (tailcall) on line 3, column 1

The build directory appears to contain janetui:

~/temp/janetui$ ls build/
CMakeCache.txt  CMakeFiles  cmake_install.cmake  libjanetui.so  libui  Makefile

@uvtc
Copy link
Author

uvtc commented Feb 2, 2022

@cody271 , thanks. When I change that one line to a relative import, the app runs!

@uvtc
Copy link
Author

uvtc commented Feb 2, 2022

@sogaiu , thanks. The --recursive option to git pulled in libui.

It looks like, when originally trying

jpm install https://github.com/janet-lang/janetui

maybe it did not recursively pull in libui? Where does jpm keep its temporary working directory? I could look there to see if its libui dir is populated...

@sogaiu
Copy link

sogaiu commented Feb 2, 2022

@uvtc I don't know off the top of my head, but I looked at the output here for jpm install https://github.com/janet-lang/janetui and saw at the top of it:

Initialized empty Git repository in /home/user/.local/lib/janet/.cache/git__https___github.com_janet-lang_janetui/.git/
remote: Enumerating objects: 50, done.
remote: Total 50 (delta 0), reused 0 (delta 0), pack-reused 50
Unpacking objects: 100% (50/50), 27.96 KiB | 2.15 MiB/s, done.
From https://github.com/janet-lang/janetui
 * [new branch]      master     -> origin/master
From https://github.com/janet-lang/janetui
 * branch            HEAD       -> FETCH_HEAD
HEAD is now at e6affdf Merge pull request #2 from faywong/master
Submodule 'libui' (https://github.com/andlabs/libui.git) registered for path 'libui'
Cloning into '/home/user/.local/lib/janet/.cache/git__https___github.com_janet-lang_janetui/libui'...
Submodule path 'libui': checked out 'd305440fa0f341d69d869c7ddca7cfd79ec99193'

That seems to suggest that jpm was fetching libui's repository as a submodule.

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:

/home/user/.local/lib/janet/.cache/git__https___github.com_janet-lang_janetui/libui

FWIW, I don't think libui is being "installed" for general use in this case but it's fetched rather for building purposes.

@kamisori
Copy link

kamisori commented May 3, 2024

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 ^^

@sogaiu
Copy link

sogaiu commented May 4, 2024

I gave it an attempt.

I still get the header file path problem:

[ 95%] Building C object CMakeFiles/janetui.dir/main.c.o
/home/user/src/janetui.kamisori/main.c:23:10: fatal error: janet/janet.h: No such file or directory
   23 | #include <janet/janet.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/janetui.dir/build.make:76: CMakeFiles/janetui.dir/main.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:179: CMakeFiles/janetui.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
error: assert failure in (zero? (os/execute ["make"] :p))
error: build fail
  in pdag [/home/user/.local/lib/janet/jpm/dagbuild.janet] (tailcall) on line 79, column 23
  in run-main [boot.janet] on line 3975, column 16
  in cli-main [boot.janet] on line 4128, column 17

May be this has to do with my using a "non-system" Janet setup.

@kamisori
Copy link

kamisori commented May 4, 2024

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

@sogaiu
Copy link

sogaiu commented May 6, 2024

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.

@sogaiu
Copy link

sogaiu commented May 6, 2024

I think the diff below is an improvement over the previous hack.

The idea is to use jpm's knowledge of where janet.h lives and pass this information to cmake via its command line invocation.

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)

@kamisori
Copy link

kamisori commented May 6, 2024

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

@kamisori
Copy link

kamisori commented May 6, 2024

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:

  (assert
    (and
      (zero?
        (os/execute ["cmake" "-B" "build" "-DBUILD_SHARED_LIBS=OFF"
          ] :p))
      (zero?
        (os/execute ["cmake" "--build" "build"] :p))))

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... 🤦

@sogaiu
Copy link

sogaiu commented May 7, 2024

cmake should be able to pick up on environment vars, so something like this should work but//.

On my system, JANET_HEADERPATH is not set by default. I install using PREFIX=$HOME/.local and don't have any JANET_* environment variables set.

so idk what coincidence made janetui "magically" compile here

If you did a default install of Janet on Windows, may be "it all just works" (TM).

@sogaiu
Copy link

sogaiu commented May 7, 2024

idk. add-dep seems to work, but somehow jpm starts to build main.c before the dependency is through...

If this is the build being parallelized, possibly serializing via jpm's --workers might make a difference...and gain some more visibility via --verbose if that's not already being attempted:

  --verbose : Show more ouput than usual and turn on warn flags in compilers
  --workers : The number of parallel workers to build with

May be using 1 for --workers will give a different result?

@kamisori
Copy link

kamisori commented May 7, 2024

May be using 1 for --workers will give a different result?

indeed it did, thank you for the help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants