Linux support

[diegoiast]

Linux is not supported yet. This should be easy.

To build (I am using clang, as gcc-13 on debian does not have support for modules):

CXX=clang-17 cmake -S . -B cbuild -G Ninja
cmake --build cbuild

Items to tackle:

• [ ] src/core/SubProcess.cppm - initial work at https://github.com/shahfarhadreza/papercode/pull/10
• [x] ALL - front include path ("" instead of "/"), seen in stdfax, UISystem... etc
• [x] src/platform/FileDialog.cpp - find a way to use platform dialogs, how about https://github.com/samhocevar/portable-file-dialogs ?
• [x] Document compilation on linux
• [x] Odities of clang17 on linux

[shahfarhadreza]

Majority part of the codebase is platform independent except the subprocess module and file open/save dialog codes which are tied to windows api. I was unable to find a good cross-platform process library.

[diegoiast]

I am using here Ubuntu 22.04, what is considered "stable":

1. gcc does not support c++ 20
2. clang does not support c++20 modules
3. I downloaded clang 17 from llvm, and run cmake.
4. To build using cmake, the default GNUMakefiles is not enough. Ninja is required.
5. For modules support, cmake needs a newer ninja. I compiled it from source.

My build command looks:

PATH=/home/diego/src/github/ninja/build:$PATH  CXX=~/Downloads/llvm/clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04/bin/clang++ cmake -S . -B cbuild -G Ninja

To build:

cmake --build cbuild/ --clean-first

I am able to build some parts, but linking will fail, as I need to link against libc++, added this to CMakeLists.txt:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++"

Some things I see from now:

1. std::jthread is not avilable for me. Using std::thread for now.
2. std::format - I was not able to make it work (include fails? dont know yet)
3. Some includes, paths etc are not working. Easy to fix.
4. Subprocess - I can workaround it, meanwhile its stubed.
5. FileDialog.cpp - stubbed.
6. std::stop_token - is not found. This is currently blocking me.

I will start sending patches, but so far, it seems that MSVC is far more c++20 ready than gcc/clang. I think that downgrading the code to use C++17 is a good idea.

[shahfarhadreza]

Hey, I see the issues. Is llvm/clang 18 available for you on Ubuntu 22.04? I'm on windows 10 and I built this project using Clang 18.1.0 without any problems.

[shahfarhadreza]

Also, std::stop_token isn't even used I think you can just remove the parameter for now.

[diegoiast]

Downloading stuff in linux is problematic. I don't see binaries here : https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.1

However, on Debian testing I do see clang17 which is more or less capable of building (apt install clang-17 clang-tools-17 and then CXX=clang++-17 cmake -B cbuild -G Ninja). I am still getting errors:

papercode/src/core/Project.cppm:212:21: error: no member named 'unexpected' in namespace 'std'

Next ubuntu is to be released soon, so I think the problem is not that big. The expected, or unexpected issues are a show stopper for me.

EDIT: Another trivial issue (just use strncpy()):

papercode/src/ImGuiHelper.cpp:59:9: error: use of undeclared identifier 'strncpy_s'
   59 |         strncpy_s(buffer, sizeof(buffer), (*text).c_str(), sizeof(buffer));
      |         ^
1 error generated.

[shahfarhadreza]

The std expected and unexpected used only in that single place. I was thinking it might come in handy handling error msg stuffs. I've been trying to use latest c++ features kind of in an experimental way. Perhaps sticking to c++ 17 would have been much more convenient. Lots of codes are already written in c++ modules format so I'm afraid I'm not going back.

Also about strncpy....I probably should replace it with something std string/vector equivalent

[diegoiast]

Well, I changed locally this function to return a bool, and that seems to work :) Here on Debian (clang17), I am now failing at this:

/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:156:17: error: static assertion failed due to requirement '__is_invocable<(lambda at /home/diego/src/github/papercode/src/Build.cpp:168:33)>::value': std::thread arguments must be invocable after conversion to rvalues

I will start with PRs now. My local copy is too messy.

EDIT: https://github.com/shahfarhadreza/papercode/pull/3 - this fixes includes https://github.com/shahfarhadreza/papercode/pull/4 - this fixes (?) process creation https://github.com/shahfarhadreza/papercode/pull/5 - this stubs out all dialogs https://github.com/shahfarhadreza/papercode/pull/6 - simplifies API to remove usage of Expected https://github.com/shahfarhadreza/papercode/pull/7 - document the build and needed packages on Debian/Testing

[shahfarhadreza]

sorry it's late in the night here and i'm not on my pc..i checked all the PRs and i will merge them in the morning.

btw were you able to get rid of that std thread header error yet?

[diegoiast]

Yes. I cannot reproduce this on the Debian clang.

Code still does not compile locally. Let's see what happens after a full merge.

[shahfarhadreza]

Pull Reqs. are merged. Let me know how it goes.

[diegoiast]

New PR: fix minor thing in the cmake. See that PR for good news.

https://github.com/shahfarhadreza/papercode/pull/8

[shahfarhadreza]

yup glad to see it running on Linux :) credits to you. And for the dialogs, there is this library called 'nativefiledialog' on github..what do you think?

[diegoiast]

@shahfarhadreza

https://github.com/mlabbe/nativefiledialog https://github.com/samhocevar/portable-file-dialogs (single header, might suit the philosophy of STB).

Any one of these should be good. Once they work for you on Windows, I will adjust on Linux (if needed).

once dialogs are fixed, I will finish the process support on Linux/Posix. Might take a few weeks, since I will not be near a computer the next 2 weeks.

[shahfarhadreza]

Excellent. I will get the dialogs stuffs done.

[shahfarhadreza]

I'm using the pfd library now. Works just fine on Windows. Changes are committed. Hopefully won't break on Linux.

[diegoiast]

Nothing broke. The "New project" link is not working on the main page. So, I cannot create a demo project... besides - all looks good so far.

[shahfarhadreza]

It expects a 'USERPROFILE' environment path variable for default project creation directory which probably doesn't exist on Linux. I will replace it with 'home()' function from pfd library and see what happens.

[shahfarhadreza]

Works just fine.

Edit: And Committed. You might want to check

[diegoiast]

Works perfectly. I checked the "dialogs" part of this issue. I have a WIP posix sub process implementation, will take a look at this "some day", unless someone beats me up to it...

Hey, it compiles and creates a wrongly named binary! (which works, don't worry):

diego@debian:~/src/github/papercode/bin$ file  ~/PaperCode/HelloWorld/bin/HelloWorld.exe 
/home/diego/PaperCode/HelloWorld/bin/HelloWorld.exe: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=d3ec53725ba18c10e905f810d4462cd1ee7e0dd4, for GNU/Linux 3.2.0, with debug_info, not stripped

[shahfarhadreza]

Oh the new project dialog had an option for selecting a target platform. Selecting Linux would have removed the '.exe' extension. Although this particular setting still isn't included in project serialize/deserialize so yeah...

[shahfarhadreza]

Nvm the option is totally missing in new project dialog...I set the default target platform to the host platform. So now your Linux build will target Linux for the project as well. I'm not sure if we even need this to be an option. Cross-Compiling I guess?