Building from source

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..

In short, How do you do this shit right?

Attached: bob.jpg (600x400, 19K)

the answer is simple;
write packages.

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)

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.

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

you have to mask/unmask your dependency.
that's the reason i left gentoo.

You can thank me later.

Just try building from source a few times. You'll see why everyone says to not.

most languages have garbage dependency management and generic build tools like make suck so hard

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.

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.

>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

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.

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?

Attached: 1543970908384.gif (460x460, 1.96M)

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

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.

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!

any good resources/guides?

I like this thread

Interesting thread, post for follow

I've been wondering mostly the same things. Compiling on Windows seems to be especially troublesome.

When you install the package, it usually just werks. If you build from source, it often doesn't werk.

i build in a chroot and make an appimage

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

>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

C/C++ build systems are AIDS and a bitch to unfuck most of the time
Especially cmake
God I hate cmake

Experienced CMake user here, what are you having trouble with?

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

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?

Reading the fucking manual mostly, it’s trash.

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

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.

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.

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...

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

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.