This project idea could have been considered complex, but the implimentation was pretty simply done, which is one of the reasons I think it was completed.
Its always nice to build something you can use on a regular basis, but its “icing on the cake” if it is available and works for others too
In my opinion, this is the top winning entry. Not to put down others efforts, some of them are amazing, but the sheer usefulness of this project can not be overstated.
I am bumping this because it was one of (or maybe even) the 1st project to be completed, so its down the #devember2021 list a bit now, with no interaction for 17days.
Part of my criterea for considering this project the #1 project for Devember2021 is:
how many people on the planet could it affect
how many of those people would use it if they had it or knew about it
how easy is it to install/use (source is 47KB zipped, with tests & examples)
is it flexible as a solution to a target outside the scope of the problem it solves
what classification does it deserve as a solution to the problem
my answers:
C++ programmers: alot. tons. millions. 100 millions? Including ALL the SerenityOS developers.
users: most of those people above who test ideas, or prototype alot, or teach solutions
extremely easy to install/use (I checked the source myself). just build and place in your PATH
yes. (wait so it could easily affect more than 100’s millions of people? yes). it is verified above.
elegant. simple. simply elegant (honestly, most solutions to this problem are fat, oh so fat ).
FYI: (re: classification)
I have uploaded a github repo with a (broken-out) copy of the last standalone version of the CERN equivalent solution cint developed by scientists (source is 13MB zipped, also the best alternative till now). To originally compile that you needed the whole CERN root project, which cint was part of (just like you need a 64bit OS and the whole ChromiumOS project just to build a 32bit Chromium Browser)
FYI: (re: affects & users)
by changing (the hardcoded) compiler, C also works (scroll up to see for yourself). Even without this change (or a way to make that flexible), the seabang project will work on any platform with GCC 2.95 up, on any OS that can process SheBang scripts (starts with #!). Even if it only ever uses the GNU compilers, there are GCC backends for:
C
C++
Objective-C
Fortran
Ada
Go
D
Java (2.95.0 (July 31, 1999) - 6.5.0 (October 26, 2018) - made obsolete since OpenJDK)
Rust
Yes, you read that right, someone is developing a GCC backend to allow the GNU Compiler Collection to compile RUST programs. I included the Java backend to give you an idea of just how many machines (both ancient and modern) that the seabang project will work on. GCJ is still relavant to some projects and to older platforms including AtariST MiNT (m68k) where GCC 2.95 is still prevelant, so this seabang project will work there too.
I could not find any standard way to define a systems preferred c/c++ compiler. I had expected there to be an environment variable. I’m currently running Ubuntu. I have not seen it in Debian either, if anyone knows of one or has a suggestion I will put the into the code. Should be easy to do. The only reason I have not done it yet is that I would like to use one that is already in common use. I may look at the CMake source to see how that decides which compiler to use.
What would be nice is if the c/c++ compiler teams took my idea and added to their compilers. That would be the best solution. It’s one Python feature I have always been jealous off.
While I’m not a judge, I do want to mention how awesome I think this project is. I don’t personally write c++ for desktop use, but I do appreciate the scope and cool factor of it.
Yeah, the only ones I know about are the common ones you set in Makefiles, or the ones that you pass to ./configure, but they are only available in the make envoriment (same with Cmake too - you could look a ./configure script to see how GNU finds it per platform) - CC, CPP, CFLAGS, LDFLAGS, etc
setting the default compiler on linux is commonly done by soft-linking cpp (preprocessor), cc (C compiler) and c++ (C++ compiler) (Buster)
Patching your PATH variable is another common way for self-built toolchains, and passing a PREFIX or SUFFIX of some type is another way. eg. TOOLCHAIN_PREFIX
I know there is a way to make it work, but I would not sweat it if I were you, someone who has multiple use need will come up with a solution, in the meantime you have PoC that it can work.
I know there would be work to get other languages working with what you have, I am just struck by the potential of what you have, and just how far-reaching even the C++ impact is (as you use it). 1992 2.95 on m68k to 2022 12.0 on aarch64 (and thats only if you target g++ excplicitly) - I have about 5 different platforms that I use to develop on, with g++ versions stretching across both those targets (about 7 different versions in total).
The potential based on what the alternatives are, before you created the project. I dont know why no one thought of your approach before now …
Anyway, I too am not a judge
(I just thought others should be aware about the overall situation)
I’ve done an update that should improve the usefulness of this app.
First you can change the compiler that seabang calls. When seabang is built and installed you can set the compiler by passing in a define into cmake.
e.g.
cmake -DSEABANG_CXX_COMPILER=gcc
If you don’t do this seabang will use the compiler that cmake chooses.
After seabang has been built and installed you can still change the compiler used with two options. Either set the environment variable SEABANG_CXX_COMPILER or call seabang in the shebang with the option --seabang-compiler=YOU-COMPILER. eg. --seabang-compiler=gcc
I have also improved the code that passes on some command line options that are passed to seabang into the compiler. Any single dash option is now passed onto the compiler.
Thats epic (hope your dissertation goes well)
at least its more flexible now.
while posting that issue, I was thinking “stuff that wont require editing the file would be better”, meaning it would be nice to pass along a seabang enabled file that will build outr of the box on a different platform (my needs being specific, having to override compiler defaults, particularly -m options)
I need to play with seabang more to understand better what I’m trying to do, to get stuff added that doesn’t complicate install or usage
cheers for that, I am sure other that might use it will find the new options flexibly useful
Actually there was another issue I saw, but I’ll put it on the GH Issues as I need to find the exact details again.
I’ve done one more update. I don’t think i’ll do any more except for bug fixes. I don’t want the code to get too out of hand.
You can now specify when you build and install seabang the folder used for temporary files.
You can also change the default temporary folder seabang uses with the SEABANG_TEMPORARY_FOLDER define.
e.g. cmake -DSEABANG_TEMPORARY_FOLDER=~/temp
This option is handy if you have a ram disk created to tmpfs.
Will make the results of the build vanish after boot and also work on read only disk systems, which is handy.
The environment varible SEABANG_TEMPORARY_FOLDER can be used to change the temporary folder used by default.
eg. SEABANG_TEMPORARY_FOLDER=~/tmp ./my-code.cpp
-seabang-temp-path=PATH Allows a specific source file to use a particular temporay folder.
This overides the compiler set with SEABANG_TEMPORARY_FOLDER and the default one.
Example, --seabang-temp-path=./bin
So for example you could point it to a ram disk. Seabang will only build the app if something has changed. So using a ram disk could help some embedded systems that have a read only drive. Because ram drive is not persistent will be built the first time its ran after reboot.
one last change (I realise this wont help the examples) use: #!/usr/bin/env seabang
Then it does not mater where in the filesystem it is installed to. Having ./ 1st in the PATH would then also find it in a fresh repo build.
When I build packages that are a part of my package repo, they normally default to /usr/local. But I often build multiple versions, and they could be in multiple /opt, ~/somewhere or somewhere else, while a package repo would install it to /usr/bin.
Nice animation too. If you use an ANSI animation, people could “cut & paste” the actual content
