[Devember 2021] [Complete] C++ as a script. seabang :D

Linux app that will build a c++ source file and run the results as if the c++ was executable. Only builds if the source file has changed. Will have dependency checking too. Just add “#!/bin/seabang” as the first line, like the cool kids do with python.

And in the usual Linux naming convention I’ve picked a name that will be hard to find in apt. :smiley: Play on words for C and shebang The #! magic thing that scripts have. You get the idea. :wink:

Main reason for the project is that I want a simple app that I can use as a way to learn getting an app added to the debian apt repositories. Or what ever they are called.

Ta,
Richard.

10 Likes

Neat, “interpreting C++” always reminds me of ROOT CLING from CERN.

What do you think of using for dependencies? A package manager like conan, vcpkg, spack, or do you want to integrate with a linux distros package manager, like looking for which *.deb package includes a header file with apt and then install that?

Will not be interpreting C++, will do just in time compiling and run the result. I’ve done some tests. And even with doing the compile, that will only need to be done if the code changes, the c++ code is much faster than a Python version of the same code. This was tested on a RPi with it’s slowish sdcard based filesystem. The compiled binary will be stored in the tmp folder.

The dependencies I talked about are the includes that the source file pulls in. If any of these change then the file will be recompiled.

First working version is up. I have some work to add some more features such as being able to pass in extra libs that you want to be linked in. Also I want to do a dependency check on the source file. IF any files it includes have changed then rebuild. This will allow you to include more source files into the one being turned into an executable. If it’s a big project could take some time for first build. But if nothing changes it’ll do some date checks then run existing built executable. I also need to change some code that has hard coded paths for the temp folder and read it’s location from an environment variable. I wish to also add an option so that the ram disk is used instead, this would be handy for file systems that are read only.

The repo is on github @ /HamAndEggs/seabang.git

Seems I’ve added my build folder to the repo, so I better go update my ignore.git file. :smiley:

To use just add (if you’ve built the app in installed it)
#!/usr/bin/seabang
To the start of your c++ file and make the c++ file executable. And you’re good to go. No more make files. Just run your source files like the python people have done for years. :slight_smile:

1 Like

Updated so now does dependency checking for any file that is included by the source file you’re running.

you can post the GH url, and it will show up as a pretty box with some info (like this):
http://one-file.sourceforge.net/

NOTE: with “/tmp/seabang”, check and use “$HOME/tmp” first

This is a cool project, and I totally get why you made it. FWIW I had a similar idea but different approach (maybe even complimentary):

Hi, when I first made the post it seemed the forum would not let me. I’ll try again. I need to work on the params a bit so one can pass params into the compiler if they need to. Like adding defines or libraries to link against. Thanks for the tip on the path. Will add that.

I’m not allowed to post links… :frowning:

h t t p s : / / github . com / HamAndEggs / seabang

1 Like

You are right, I forgot that the forum requires a build up of trust based on your user interaction over time. NP I’ll post the GH repo link:

EDIT: I just remembered that I made something like this for BASIC on linux, that archived the script (or everything) to a .baz extension, an automatically ran the interpreter, allows password and encryption, as well a multiple script and asset storage, and simple distribution

1 Like

Just done an update to add a new option to allow you to build a debug version of the code. Also fixed a bug where if it failed to compile but there was an exec from a previous build it would run the previous version of the code.

glad to see this is coming along, keep us upto date, I’d like to see this completed - very useful

Filled in the readme.md file and filled out a help page in the app. seabang —help to view.
Baring any bugs to fix, it’s done and finished. :slight_smile:

Just fixed two bugs. Did not include the current working directory for the search paths for the compiler and the code that checks for changes to the source files dependencies.

Found it as I’ve been using this tool myself. The tool makes writing code to test things out very easy and allows for really fast iteration.

:slight_smile:

Again, great job. You will find more edge cases as you use it more, bugs, tweaks, features, etc

I looked through your seabang.cpp an noticed a couple of things. I am guessing you are building and testing on Windows machine, may under WSL.

  1. technically “.exe” is fine on Linux too, unless the machine/OS is setup to recognise and run windows binaries, then there will be an issue.
  2. you force g++ when executing the compiler.

for 1) on Mac .app is the “executable” extension, also on MacOS/Linux you can not run any binary that has not been chmod a+x code.bin. So maybe the way to address this is to allow “Windows App” & “MacOS App” to adjust output, thgis way you can also compile and runs a Windows .exe on Linux (for example). Probably the real soluition will come from testing inside a real OS (even if you do that via a VM).

for 2) you can try pick up (or test) the CPP environment variable first as I know not every system has g++ as the default C++ compiler. With Linux/BSD I know a which g++ will also get you a full path to the binary. As another senario here I have OS’s set up that dont use the default g++ (or c++ alias), but the ones I use are not always in the same place ( /usr/local/ , /opt/ , or /home/) and therefore also not in the PATH environment variable, so usually I just state where the compiler path is, either with CPP=/opt/gcc-2021/bin/g++ or CPP_PREFIX=/home/rpi/gcc-14/bin if I want to also use that linker or other tools (FYI these are also the default variables tested by the make tool). Again, some thought and experimentation on a real OS will help out here.

EDIT: This 2) suggestion would actually allow #!seabang to work with other compiler languages

EDIT2: Optionally, if these two settings are added in, then referencing a ~/.seabang defaults file (in the home directory) may also be a (good?) idea, although I dont know how useful or easy this is to impliment on a Windows machine (that is not using WSL/Cygwin). Also what about g++.exe on a non-WSL system … (again, edge cases).

Apart from those two main suggestions, atm I cant really see what else might be needed without actually starting to use it, which is cool

I for one am really glad you chose to do this project for #devember2021 and it turned out to be a relatively simple soulution too, great work and hope to see you back next year with another interesting and useful project.

Cheers

Paul

1 Like

Also FWIW (ie everybody else) I am not a C++ programmer, but all my C code and apps are in .cpp files and use g++ or c++ (alias) to compile and build the projects. Often the only “tweak” I need to make are the “includes” (that apply to C functions). So this project should work fine for most C programmers too …

Hi Paul, thanks for the feedback.

I’m on Linux, have been for many years. I do have a Windows laptop that I use when a client has some windows software. Very rear these days. I work mostly in the industrial sphere supplying custom Linux based solutions. But will be worth checking for compatibility with the Linux port for windows.

This app was only ever considered for use in Linux. I will investigate the environment variables for compiler selection. Maybe for an update. Really depends on how different calling them maybe. Be nice if, with minimal changes, would run on other POSIX systems.

I will test for .c files too.

As support for other compiled languages, I think I will leave that to others. seabang was meant to be a small app with minimal dependencies. means it’ll build for more people. It’s something I have wanted to write since I first saw that the python people were able to run their source files. :slight_smile:

1 Like

Just tested some c code. Seems to work fine.

Just added the file c-codetest.c to the repo for testing that. the classic hello world.

1 Like

I thought it would, without any changes. I mentioned other languages more for future readers, especially since your code doesn’t do anything C++ specific (except the hardwired g++ reference), so at least for other GNU compiler languages, it should work “out of the box”.

Appologies re: Linux/Windows “suspicion”, I wish I was in a position to help with platform testing, but I have put it on my TODO list when things change here. Sorry for implying you were a Windows developer, any resulting “offence taken” should be forwarded to /dev/null :wink:

1 Like

You sound like someone who hasn’t been programming long enough to know why that’s a bad idea. You’ll figure it out though.

In addition after looking over some of your code I would recommend eliminating all definitions from your header files. Only declarations should be contained in headers. (in particular you have a class definition, you should change that to a declaration and define it within the companion implementation file instead of within the header itself)

The only time you would have to define anything within a header is if you have a template class or function that you do not want to explicitly declare typing on: aka enable compile-time type generation.

Other than that some questions are raised about why you’re using C-strings instead of std::strings, but hey if it works it works. ¯_ (ツ)_/¯

On the whole the project seems to only be a proxy for calling g++ directly. The compiler already does what you’ve described to begin with: it only compiles files that have changed. It’s called incremental build. If you want to get real crazy you could add an interpreter for a sort of shorthand that allows the programmer to easily pull in third-party libraries and add new files, but that’s already been done as well: look into CMake or QMake.

“You sound like someone who hasn’t been programming long enough to know why that’s a bad idea. You’ll figure it out though.” That’s a little presumptuous and very condescending.

I’ve been coding for over 40 years and doing it professionally for nearly 30.

“I would recommend eliminating all definitions from your header files.”
I assume you’re commenting on the TinyTools.h header? This is a set of commonly used bits of code that I have collected over the years. It is not specific to this project so there will be some definitions that may, to the causal observer, look like they are not used.

“why you’re using C-strings instead of std::strings” Habit and some old code. Fair comment. I am slowly weening myself of these. :slight_smile:

“The compiler already does what you’ve described to begin with: it only compiles files that have changed” This is incorrect, g++ will always build the source file, if it’s changed or not. You need to use a tool like make to get, as you call it, incremental builds to work. Incremental builds that you refer too are as Microsoft defines them. Incremental builds can also mean a method of software development.

“On the whole the project seems to only be a proxy for calling g++ directly”. Yes, it is. That’s the point. You call it via a shebang (google shebang Unix). I think you don’t understand it’s use case. Using make or another other tool requires other files to be included with the source file. Using seabang all you need is the source file.

“allows the programmer to easily pull in third-party libraries and add new files” It already does that, you can specify on the command line libraries to include. To add extra source files then you’re better of using a proper build system, multiple source files are out of scope for the application. But you would have seen that if you read the manual, “Allows you to run c++ source file as a script”.

Thanks for your feedback, in future consider your tone and the audience your addressing.

3 Likes

bar any bug fixes or new features I may or may not add over time, I consider this project as complete. :slight_smile: Been using it for a few weeks to try simple ideas out quickly.

Working a treat and as I expected.

1 Like