/g/ - Mental masturbations about codebases, packages and how should we structure our projects - Technology

Anonymous

Mental masturbations about cod(...) 10/03/25(Fri)15:25:27 No.106781203

File: ef8110ae7dd4c291a7c8cdeb5(...).jpg (128 KB, 700x995)

Mental masturbations about codebases, packages and how should we structure our projects Anonymous 10/03/25(Fri)15:25:27 No.106781203 Archived

This post is NOT about design patterns, not about any programming language in specific, hell, probably not even about programming, but about project structures. I was scouting the Plan 9's source code and i saw how the codebase was structured and it was glorious. Everything very organized, very easy to read and well integrated. At some point i came across this mkfile from acme.
</$objtype/mkfile
BIN=/$objtype/bin

TARG=acme

OFILES=\
    acme.$O\
    addr.$O\
    buff.$O\
    cols.$O\
    disk.$O\
    ecmd.$O\
    edit.$O\
    elog.$O\
    exec.$O\
    file.$O\
    fsys.$O\
    logf.$O\
    look.$O\
    regx.$O\
    rows.$O\
    scrl.$O\
    text.$O\
    time.$O\
    util.$O\
    wind.$O\
    xfid.$O\

HFILES=dat.h\
    edit.h\
    fns.h\

</sys/src/cmd/mkone

$O.out:    /$objtype/lib/libframe.a /$objtype/lib/libdraw.a /$objtype/lib/libthread.a

edit.$O ecmd.$O elog.$O:    edit.h

syms:V:
    $CC -a acme.c > syms
    for(i in ????.c) $CC -aa $i >> syms
And this mkfile has lots of references to the operating system itself and more specifically the /sys/src/cmd/mkone made me wonder if we are doing our codebases wrong. It's going to be weird, but we have to split our projects into different repositories? Instead of thinking on different software, shouldn't we be writing, lets say "our OS", based on some other OS containing our stuff, so we can reuse parts we already done before? And what about other things, like "/usr/share" for non-code resources and documentation we already worked on? Are we using computers wrong?

Anonymous
10/03/25(Fri)15:37:24 No.106781319

Anonymous 10/03/25(Fri)15:37:24 No.106781319

>>106781203
>but we have to split our projects into different repositories? Instead of thinking on different software, shouldn't we be writing, lets say "our OS", based on some other OS containing our stuff
I'd say this is something to think about when you are getting to around 10 different custom binaries that work together. the application structure would pretty much be the same but for packaging it would have to switch to some sort of launcher to curl the necessary shared libraries

Anonymous
10/03/25(Fri)15:46:44 No.106781419

Anonymous 10/03/25(Fri)15:46:44 No.106781419

>>106781319
The problem here is "reuse". How do you reuse code that was written for a different project? You split the package into a different repo and mark it as a dependency? Or you make one giant repo containing all the libraries you need already on the repo? What about versioning of these packages?

Anonymous
10/03/25(Fri)15:50:33 No.106781456

Anonymous 10/03/25(Fri)15:50:33 No.106781456

File: stock-photo-pretty-girl-l(...).jpg (815 KB, 1500x1600)

815 KB JPG

>>106781203
>plan 9's source code
>how the codebase was structured
>glorious

Anonymous
10/03/25(Fri)15:56:24 No.106781524

Anonymous 10/03/25(Fri)15:56:24 No.106781524

File: 1756461126505780.jpg (152 KB, 1600x900)

152 KB JPG

>>106781203
>http://9p.io/sources/plan9/sys/src/libc/fmt/fprint.c
Yeah dude. Glorious dude. Just putting some small functions in a separate file will make your code more "structured" and navigable.

Anonymous
10/03/25(Fri)16:04:23 No.106781634

Anonymous 10/03/25(Fri)16:04:23 No.106781634

>>106781524
https://git.musl-libc.org/cgit/musl/tree/src/malloc/realloc.c

That's literally how a libc is usually organized. You have to remember that C is not a front-end lang for a complete software but to the object code, and then you take an linker and use that object code to build a software. You can implement an interface (the header) in many file as you want, even with just one function per file.

Anonymous
10/03/25(Fri)16:12:24 No.106781718

Anonymous 10/03/25(Fri)16:12:24 No.106781718

File: 1759322745946314.jpg (205 KB, 850x1277)

205 KB JPG

>>106781203
>It's going to be weird, but we have to split our projects into different repositories? Instead of thinking on different software, shouldn't we be writing, lets say "our OS", based on some other OS containing our stuff, so we can reuse parts we already done before? And what about other things, like "/usr/share" for non-code resources and documentation we already worked on?
I did essentially this (mirroring the requisite FHS directory structure) and found it was useful for adding custom profiling and string pools across projects, but there wasn't much reuse/sharing besides that

Anonymous
10/03/25(Fri)16:24:30 No.106781874

Anonymous 10/03/25(Fri)16:24:30 No.106781874

>>106781634
That is how retards organice code. Nobody mandates that, even if you have can have multiple objects files and myriad of code units there's no point of doing it, you are just segregating your code and making it harder to maintain. My allocator is like a single 10k - 12k lines file plus a header file, and the code is all in one place.

Anonymous
10/03/25(Fri)17:06:48 No.106782355

Anonymous 10/03/25(Fri)17:06:48 No.106782355

>>106781874
retard alert

Anonymous
10/03/25(Fri)17:13:47 No.106782429

Anonymous 10/03/25(Fri)17:13:47 No.106782429

File: videoframe_34737.png (147 KB, 320x240)

147 KB PNG

I think the real deal here is *install* those packages. Make your $HOME mirror the /usr, have a $HOME/{lib,include} and in the $HOME/src you have multiple repos instead of just one. Every package becomes a library that you install locally on $HOME/lib and $HOME/include. For non-code resources, you put them on $HOME/share.

Anonymous
10/03/25(Fri)18:09:10 No.106782888

Anonymous 10/03/25(Fri)18:09:10 No.106782888

>>106781203
Didn't read but
>Are we using computers wrong?
Yeah. And project/os architecture is faggot.