What does your OS look like? (Screen Shots..)

[AndrewAPrice]

Only thing: How do you know which object file should end where? I mean: If you have several cpp/c/asm files and want to link the resulting object files to a complete program, you have to tell it explicitely, or not?

My build system has two targets: "perception" (my OS) and "local" (the host OS, where it calls the system's C++ compiler) - a secondary goal is to one day be able to build hobby C++ programs and be able to compile it both for my OS and locally! There are three configurations: "optimized" (which does whole program optimization), the default (fast build), and "debug" (symbols and stack traces.)

By build system creates a temp directory called "build/" which has some interesting things in it:

• <target-configuration>/ - A mirror of the "source/" tree where the object files go. e.g. "source/abc/def.cc" turns into "build/perception-optimized/abc/def.cc.o".
• <target-configuration>/dependencies.json - A map of source file => dependent files (headers). GCC can output all the header files that a source file depends on. I read it, store it in here, and use it to determine if to rebuild a source file if any of the dependent timestamps are newer than the object file.
• <target-configuration>.lib - (For libraries) The object files linked together into a single object.
• <target-configuration>/.app/.exe - (For programs) The final executable.

You have the problem of everything being called "perception-debug.app" or "local-optimized.exe" , but I have a final step in my build system that copies it into the "fs/" tree and renames it to the program's name, then turns it into a bootable ISO image. There's no reason you couldn't do something similar if you wanted to package a program for distribution.

Usage is:

Code: Select all

# Builds application "Hello World" for the local host with all optimizations and runs it locally.
./build run --opt --local Hello World
# Fast builds everything for Perception, turns it into an OS image.
./build all
# Builds everything with optimizations, turns it into an OS image, and starts QEMU.
./build run --opt
# Builds the "musl" library
./build library musl
# Builds the application "Hello World"
./build application Hello World

One day I hope to add a `./build test` for unit testing a package.

[neon]

https://gitlab.com/nakst/essence

At a quick glance, it looks like you have your own build system? (Or is it just a program that invokes make?)

Now I'm not alone!

Hi,

So, er...no worries, you aren't alone in this. I wrote a build utility, "nbuild" back in 2016 -- the original version just recursively scanned the source tree and ran make. Since then I paused development efforts to focus on a complete SDK and build system. Visual Studio didn't represent the source structure very well as all being independent projects, and I wanted a way to self-host and keep the source repository independent, small, and clean, without unnecessary clutter of 3rd party applications or the need of a complex build setup. I plan to rewrite "nbuild" when everything is ready, but it would still use our internal "nmake" for building projects, "nbuild" would hopefully be smarter with dependency tracking. I should be able to do something like "b -x86 -debug" and it should "just work" by invoking nmake, nimg, etc to produce "mydisk.img". OS and toolchain specific build options are hidden in global environment makefiles (right now, they are in the form "tool-os-arch" like "link-win-x86.def") that are selected and included in the parent makefile.def depending on project-specific options (which has its own per-project makefile.) Per-project specific makefiles are kept very simple (just defines SOURCES, LIBS, TARGETNAME, TARGETTYPE, etc.) Project is of course still ongoing -- in all honestly though its been a lot of fun researching.

[AndrewAPrice]

has to figure out where each operating system or each Linux distro, gah! puts each and every one of the headers and libraries it needs.

This is a real problem! It shouldn't be this hard. That's one motivation for me to make a simpler build system for my OS.

[eekee]

has to figure out where each operating system or each Linux distro, gah! puts each and every one of the headers and libraries it needs.

This is a real problem! It shouldn't be this hard. That's one motivation for me to make a simpler build system for my OS.

Me too. Some languages have kind-of solved it for anything written in that langauge, having package managers of their own, but I'm not keen on package managers and am thinking of other ways of organizing everything. I'm even thinking of multi-access filesystems so the user-visible tree as such is just one way to find things, not the only way.

[nexos]

I planned on writing my own build system, and I sort of did (just a very large script which does a lot of sanitization and has some nice abstractions. I actually use CMake, and then the aforementioned script calls CMake. It works quite well.

[Thunderbirds747]

Lots of applications

That GUI looks impressive, but I suggest that there should be a bit more functionality, such as date/time displayed on the taskbar (similar to Windows NT 3.51 NewShell and up), an in-house support for Python, a self-hosting environment and a programming IDE (in case it will be too hard, no offence)
I give it a 10/10!

[nakst]

Shutdown modal.

[eekee]

Showin off dat blur! Nice!

TimothyARyazanov reminds me I really liked it when I could have almost any program I wanted in a dock or panel. Various FVWM modules could "swallow" literally any graphical program. I was glad of this when I needed multiple timezone clocks. I later stopped bothering with configuring FVWM to swallow windows; it was difficult to set up. Instead, I had them open in specific positions and FVWM to avoid that area when placing windows. That was much easier to set up and worked well. In between, I used WindowMaker which would dock icons which worked with X11's icon window extension. Because the dockable clock programs were launched with a normal command line, I could set the timezone for each clock. This was impossible with Gnome of that era which had a very opaque, unscriptable interface to launching panel applets. I was hardly a programmer in those days. Documentation was horrible, code was worse, and the biggest obstacle of all was I was sinking all my creativity and attention into something else.

[Armature]

Some of you guys have such amazing OS', kinda makes me nervous about showing my progress so far lol

[eekee]

@Armature: There have been plenty of screenshots like yours and simpler. Well done on getting a file system working. Dark blue on bright white is smart and most unusual for a text display. I'm not a fan of white backgrounds, but any high-contrast display is, for me, an improvement over the default low contrast of PC text modes.

[ilmmatias]

Finally implemented backtracing (with the symbol name being resolved), this should make debugging easier, unlike before, that I always had to just grab the instruction pointer, manually find the function using the address, and try discover what went wrong/what other function could have called it.

[Armature]

@Armature: There have been plenty of screenshots like yours and simpler. Well done on getting a file system working. Dark blue on bright white is smart and most unusual for a text display. I'm not a fan of white backgrounds, but any high-contrast display is, for me, an improvement over the default low contrast of PC text modes.

Hey man thanks, I've spent the past few days working on Text input, that poxy backspace really got me lol. I tried uploading a video of It working but the file was too big. I'll try creating a smaller video

[CorruptedByCPU]

Hey!

I managed to write simple graphics library (named: RGL - Raw Graphics Layer)

So, I'm ready to finish my Tetris clone

https://www.youtube.com/watch?v=e07igXIsiE4

[Armature]

I got my system running on my machine!

I'd show you a picture but apparently the maximum size is 128KiB.

[klange]

I got my system running on my machine!

I'd show you a picture but apparently the maximum size is 128KiB.

Most people upload their screenshots to external services.



I hacked together some basic TLS support and was able to build the new multithreading-capable version of my bytecode interpreter, so I can run this little threading demo that generates noise: