Some time ago I compiled some C++ programming
Since that time I rarely compile anything.
I simply install, uninstall, and repair if and when necessary.
Backups are essential.

I did in my early Slackware days. I don't even remember what it was but I remember doing it for a few oddball programs on Slackware. It was kinda neat to watch.

Yes, I often compile from source, both my own code and open source code by others. The pre-built applications in repositories are often not as up-to-date as I would like. Compiling from source also provides access to the newest releases and development branches.

I had to compile code for my modern and peripherals back in the day. So i has to get the information from Windows and download the source code and compile them make the install cd with the Linux os and the new drivers i has compiled. The first time i missed a drive and had to go back to windows and start over. Got it the second time.

Yes.

When I work using gentoo or linux yocto, it is common to me to compile open source applications.
Under Ubuntu 18.04 I have also compiled Elmer, a FEM simulation tool, and NGSolve that is a mesh generator

Open source doesn't mean that the source code comes with the developer of it that will hold your hand for you, telling you what each line does.

Open source means...
I have made something that I want to use, here it is if you want to use it too. Another words, anyone can see it, and use/modify/change it.

If the source is C for example, and you know nothing about C, then...learn C if you want to understand the source code. That may sound overly simple, but that is the answer to understanding source code.

bash
http://mywiki.wooledge.org/CategoryBashguide
https://www.gnu.org/savannah-checkou...nual/bash.html

python
https://docs.python.org/3/
https://www.riverbankcomputing.com/static/Docs/PyQt5/

C
http://www.open-std.org/jtc1/sc22/wg14/
https://www.gnu.org/software/libc/ma...mono/libc.html
http://www.open-std.org/jtc1/sc22/wg...docs/n1256.pdf
https://gcc.gnu.org/onlinedocs/

C++
http://www.cplusplus.com/reference/

fltk
https://www.fltk.org/documentation.php

If you should need to modify something to compile it.
Or you can write your own.

Yes. For a while -- in my earliest Linux days (Slackware 2.x) -- compiling the kernel was a fairly common activity. Downloading the kernel sources and patches (they were much smaller back then but it still took a heck of a long time via modem) and compiling via "menuconfig" was something of a right of passage. It's been a long time, though, since I felt a need to run that.

For a long time, I was compiling the components of my web server stack -- Apache, PHP, and PostgreSQL -- from sources---the biggest reason being PostgreSQL. On occasion, upgrades had to be done pretty carefully as the internals of the database might change and allowing a package manager to update the binaries could be problematic if the recommended way of moving to the newest version required a dump/restore process. I've never seen a package manager provide any warnings when that sort of thing would be necessary so I'd never have this scheduled to run automatically. Only recently -- on my test environment only -- have I begun trying to upgrade the whole stack using the package management system but still do that "on-demand". Even so, I'm still leery of that sort of upgrade as there's no set of release notes that I can inspect before embarking on a software upgrade -- without visiting a bunch of web sites, that is -- that would let me know of any gotchas I might expect following the upgrade. I'm not sure how I'd even do that when the package manager informs you that you have 1,700+ updates to install---and that's actually happened!

The other day I found that my package manager had botched the dependencies for streamtuner2 and it wouldn't run. While I was working out the solution to that problem, I grabbed the old streamtuner tarball and compiled it to get the music streaming working again.

I still find that -- except for critical updates to the kernel and major libraries that I'll still farm out to the package manager -- there are still good reasons to compile applications from sources. For those, I keep "/opt/app" as a separately mounted filesystem that is unmounted to keep out of the way of OS upgrades. Occasionally, I'll need to recompile applications that have been installed under "/opt/app" but when I do, the "configure_app-name" script is right there to get the process started. Reverting to a previous version? Easy, peasy. Compiling applications and installing them under "/opt/app/app-name-version" with a symlink pointing to "/opt/app/app-name" works very nicely. Don't like the way the new version works? Stop the application, remove and redefine the symlink back to the previous version, and restart. New version working just fine? Clobber the previous version's directory tree. Not sure how you could do that with apt-get, yum, YaST, or whatever.

Cheers...

The most exhaustive compiling of open source that I did was follow Linux from scratch.
More recently I did some crosscompiling of uboot, kernel, and busybox in an embedded Linux course.

When I compile open source projects it is actually just running make.
And nowadays I get almost everything from the package manager.
Even for the embedded development there are tools Lime buildroot and yocto that wrap three compiling four you.

Yes

Yes
Postgres, asterisk

I've compiled various versions of R since 2.15.1 as I'm a Slackware user since 1995 and there is no pre-compiled version of R for Slackware. I've also compile JAGS, a package for Bayesian analysis, ardour and some of its dependencies.

That's why we have open source, so that I can compile the code I need for the machine I want to run it one, even if the distro-keepers think that that's a bad idea, or haven't got arround to patching/ updating / approving changes yet.

And of course fix things we see are wrong / silly.

What's frustrating is when you go though all the hassle of creating a patch and submitting it, and upstream aren't interested in it. The first time I met that was
back 15 years ago, or so, when I had dial-up networking and I was annoyed that my carefully callibrated hardware clock (as much as possible, anyway, so drift was down to mere tens of ms per day) was getting shifted by 0.5 seconds every reboot. Patch submitted, (the linux kernel applied clock updates half a second after it was set at the time, if I remember correctly), and the patch was rejected because '500ms isn't significant, and it's only a factor on linux' or something like that.

I doubt the patch applies now, and with broadband it's much less an issue, but it sure was irritating when ntpd didn't have burst mode, objected to big clock skews, and my typical dial-up to run fetchmail, kill the link after 5 seconds idle, wasn't long enough to pick a reference clock with such a big time diff, let alone sync properly.

I have compiled many programs, libraries and quite a few kernels. My own free software, when I wrote it in C++, was published as source-code only.

Among the things that I still frequently compile are:

• The GnuPG bleeding edge development version from Git
• ... in consequence some of the libraries needed by GnuPG
• Mutt from Git or Mercury
• slrn, to see if there is still someone bothering...
• Ruby. It works sometimes. Most of the time it does not and I take the package from my distribution.
• tidy-html5 (though I do xhtml, only. And althoug CMake means an extra-effort and yet another procedure to follow.)
• vim

When I began digitizing my vinyl-records, gramofile came very handy. I forgot, why I modified the program, myself, prior compiling, but it had served me well for a while. I remember that all Lynyrd-Skynyrd-mp3s that I still listen to, nowadays, had been copied from vinyl with gramofile. Big Hug, Anne!!!

Having discovered PORG a few years ago, I am at complete ease with installing and uninstalling software from source.

Yeah pretty often, mostly production applications where no official appimage is provided and the distribution's binary is light years out of date...
or just to play around with the C++20 standard and see how the compilers are holding up.

Plenty of times early on in the 1.18.x then later the 2.x kernel series. I also ran Gentoo for a time but recovery from my own screwups were difficult and I moved to SuSe and the rpm format before settling on Debian offshots.

Today there are still a few utils that I want where I use the git repository to checkout and compile when updates are fetched.

My own coding skills are too rudimentary to fix complex issues, but single changes I can manage. Python is a different beast and I can usually track down the issue although at times the fix is more burdensome.