I see it everywhere; newbies being discouraged in every forum from building from source when they don't have to. To the point of it turning to a phobia for some. I don't want to be a newbie. I want to learn in order to decide for myself if I want to build from source or not. The steps of building from source are in every README file and there's no need to talk about them. My question here revolves more around best practices. Jow Forumsentlemen who build from source regularly; how do you do it? How do you make sure your system remains indefinitely maintainable and without any useless deps/libraries hanging around? How do you keep track of what went where and how do you decide which folders should be in the makefile when editing it to keep a uniform system? How do you stop yourself and the package manager from interfering with each other's databases when shared deps exist? How do you utilize tools to maintain/keep track of/verify/point at programs and sources? How do you resolve missing dependencies and what common problems do you handle? How do you update things? How do you choose options before compiling? etc..
for example, if you're on arch, don't "sudo make install" on your real root, write a PKGBUILD, and use makepkg to build and install it as a native arch package (and if suitable, throw it on the AUR to benefit others)
Matthew Jones
For a week I've been trying to get Gentoo (Funtoo) to work and it shits itself at the videocard driver stage - I fall in some dependency loop.
Fuck that, I want my shit to just work.
Jace Edwards
i still dont know how and also sofware insallation is still kimda shit on linux gnu. i use manjaro most days but some of this shit makes no sense. all these weird extensions and wastes of time. whereas windows i just use an exe or msi
Eli Cox
you have to mask/unmask your dependency. that's the reason i left gentoo.
You can thank me later.
Luke Butler
Just try building from source a few times. You'll see why everyone says to not.
Grayson Gutierrez
most languages have garbage dependency management and generic build tools like make suck so hard
Asher Hill
This poster gets it. I cut a corner, and run a Nexus server on my home network, so when I build something for an architecture I might use more than once, I throw it up there to push out to my other boxes on 'update'. Internally, my Dev team uses git -> Jenkins -> Nexus for build management. The tools have gotten so dumb easy that I found it painless to roll out at home. It really irks me that a lot of the devs we interview for entry level and junior jobs don't have a basic grasp of vanilla make, let alone cmake. I'm sure it's an issue with curriculum, but those things are open source and basic knowledge opens so many doors to getting the right versions of things in the right places. The GNU Radio project is a great example of 'installer help gone wrong'.
This is definitely a philosophy difference between the two platforms. Unfortunately Microsoft will always win for ease of use here. It seems like every few years a different concept comes out on Linux (currently flatpack comes to mind) for cross-distro 'packaging', but they all come with tradeoffs.
Henry Roberts
I see a self-perpetuating problem here where devs don't really understand building and packaging, so they write bad make files, which new users find and think 'building from source sucks'. I find makefiles in small projects with hard coded paths or distro-specific references often- and that's an instant stumbling block for someone used to Ubuntu trying to move to a redhat derivative for the first time.
Austin Diaz
>newbies being discouraged in every forum from building from source when they don't have to. it's one of those "if you have to ask, you don't need it" things even if you tell someone how to configure/make/install, what good is that if they didn't actually change the program in any way, and just ended up with the same binary as the one provided? not to say "building from source is always a waste of time", because that just doesn't make sense, /someone/ has to build things from source, but for most users, 'stock' binaries will do the job, and building them yourself verbatim is really just a waste of time
Carter Hughes
I don't disagree with any of this. Just pointing out, lots of projects don't have the fastest maintainers on some distros, so building from source (even on the prod branch) is sometimes a much newer version than the binary in the repo. Git comes to mind here.
Ethan Sanders
Since we're on the subject, can we talk about autohell for a second? Some projects say to autoreconf -i, some just skip right to the ./configure step. autoreconf just generates a configure file from some bullshit, maybe m4 macros, who knows, but some projects insist you do it, and some just give you the spat out file to run yourself. What's the difference between the two? Is there occasionally system-specific special sauce that happens during autoreconf? Is it just the difference between developer laziness and not?
yea, there's a bunch of things i prefer the 'git' version of, some distros provide a means for packages to simply pull sources straight from git/hg/svn/etc, so assuming the dependencies/build process hasn't changed (for most programs, these don't change often), it will build the latest code without constant modification by a maintainer the AUR for example, has "-git", etc packages. gentoo has "-9999" packages which serve the same purpose
Mason Rodriguez
These two posts are related. Autotools has always felt like a crutch to me. It's to help devs who want to get their code on multiple platforms without understanding the underlying compiling and linking.
Logan Garcia
OP here.
Knowing how things originally work is my goal. Having a good understanding base of how building works is the reason you guys see building into packages as a shortcut. I don't know the best practices of that base knowledge. I haven't come across a concise guide either..
But it is not a waste off time for me because this is not a question of which to me.. It's a question of how. I want to learn the right way to build. I want to change the program configurations and maybe even patch it to my system's needs. I don't want to be limited to the defaults. But first things first: Building basics. Things like how the binary should go to /usr/local/bin
That's a good point!
Aaron Ross
any good resources/guides?
Carson Rodriguez
I like this thread
Jace Cruz
Interesting thread, post for follow
Liam Lee
I've been wondering mostly the same things. Compiling on Windows seems to be especially troublesome.
Bentley Johnson
When you install the package, it usually just werks. If you build from source, it often doesn't werk.
Brody White
i build in a chroot and make an appimage
Anthony Jenkins
Start with getting stuff to work in /usr/local/ or /opt and then go from there to get stuff working in your package manager
Start with basic Makefiles then move to CMake and Meson, autotools is only useful for applications that need to support a bunch of older unixes
It's not really that hard, plus you need to be able to do it if you want to work on open source that's written in a compiled language
Check your distro package manager documentation for best practices, other then that there isn't much. Every program has its own set of specific build requirements. You may just need to ignore the haters in this thread and get more practice
Parker Reyes
>Having a good understanding base of how building works is the reason you guys see building into packages as a shortcut. building a package isn't a shortcut simply put, making a package is simply; - the same instructions to build the package manually - metadata like name and version for the systems' use that's it, you still effectively are building it yourself, the only difference there is that instead of writing the commands into a terminal emulator, you're writing them into a script to become a package really, open a PKGBUILD, it's just a bash script, and the 'build' function is the commands to build it, as you'd see in build instructions
making a package has advantages - the most functional way to write down how to build it and what dependencies it needs on your distro - is quick to modify and rebuild if you want to add patches or update version - easy to share - results in an installation which is managed properly, so it can be queried/uninstalled/upgraded/etc cleanly, just like any other package
Landon Perry
C/C++ build systems are AIDS and a bitch to unfuck most of the time Especially cmake God I hate cmake
Isaiah Robinson
Experienced CMake user here, what are you having trouble with?
Jack Turner
if "cc *.c " don't work
then you're just using a build system to compensate for ur obsession with makin shit more complicated then it needa be
all a build ststem gotta do is don't recompile shit that don't needa be recompiled
Ryder Miller
not the other guy or OP, but i'm a lurking junior dev and have never used CMake. why should i use CMake instead of Make? What do they do differently?
Henry Hughes
Reading the fucking manual mostly, it’s trash.
Anthony Thomas
oh how about havin to compile this cmake shit in the first place you got like 50 dependencies for shit ya don't need lol
like can I just type "make" and not jump down the rings of dependency hell like a cow bein led to slaughter
Dylan Cooper
I agree, if all you need is that then use a Makefile. CMake is a makefile generator. It can generate many different makefiles for different systems including IDE projects. The official docs are mostly reference, if you need tutorials you have to look elsewhere. If you don't need it then don't use it.
Landon Taylor
A manual describes how to fucking use something. It is not just a reference, but I guess not being obtuse as shit would mean the faggots who make cmake can’t sell as many books. It’s pretty fucking obvious what they’re doing and it’s fucking disgusting.
Carter Miller
nar I mean say I want to install little tucker's trip to the chocolate factory
to get it to build I need to install cmake. sigh okay ...
now I downloaded cmake sources. oh shit now I gotta install some more shit I don't have.
they jumpin me through the hoops ya dig?
all cos someone thought they needed somethin else...
David Baker
but yeah, ultimately my fault for wantin to play in the chocolate factory as little tucker so bad. guess it's the price ya pay. lmao
John Watson
There are plenty of free learning resources to choose from, you don't need to buy anything. When I learned I read the mailing list a lot and looked at real CMakeLists.txt files I could find in actual open source projects. It's even easier now than it was when I learned because you can find 1000s of examples on github.
Also writing a good technical book takes years and selling them is a perfectly acceptable thing to do. When you become an expert in something you too can write a book and sell it.
You can disable a lot of the dependencies, and even if you don't it's still not anywhere as near as ridiculous as trying to compile GCC or LLVM.