compilation step-by-step

[bad sector]

Two reasons why I (probably no alone) think my need for increased compiling from source is going to rise: the increase in security threats and the rising complexity of some of my user-level 'apps'. The security aspect needs no intro, the other one I just came across the other day when I _discovered_ that fluidsynth had to be compiled with jack ALREADY installed for it to have jack support.

https://www.linuxquestions.org/questions/slackware-14/help-me-help-midiware-docu-shop-4175713408/

The traditional way to compile used to be

./configure
make
make install (as root)

I think I am not alone in this, I'd like to ask devs to try to stick to the above instructions but in all cases to clearly document the required procedure so that non-programmers might be able to read their way through it.

TIA



--
Buying foreign is an expense, buying domestic is an investment.

[Paul]

The stuff I've built lately, NONE of it worked like that :-/

And when people deliver source, there is no longer a
courtesy INSTALL with that style of recipe inside.
Instead, the user is supposed to recognize a pattern
in the 40 disparate configuration files in the main
directory and conclude "oh, this could be a cmake".
"Or maybe it's a mach with ranch dressing". It really
is pathetic.

Even at the peak of ./configure expressive power, only
a few developers provided good feedback to the "operator"
as to what optional stuff was not going to be included.
It's an art doing those.

Just as some genius developers (subject matter experts),
could not handle argc and argv if their lives depended on it.
They had some great code, but the user could not get the
benefit of most of it, because the command line
invocation was so silly (did not follow accepted convention).

And please, don't give me more of this "my source is my
documentation" bullshit :-) If it's not apparent how
many build environments are buried in your tree, it could
take absolutely-freaking-forever to figure it out. Some
people even leave makefiles in the thing, that don't
belong there. If there is detritus in the tree
(developer droppings), they just leave it.

Paul

[Mike Easter]

bad sector wrote:
> Two reasons why I (probably no alone) think my need for increased compiling from source is going to rise: the increase in security threats and the rising complexity of some of my user-level 'apps'.

IMO, ordinary intermediates like myself 'shouldn't have to' compile; the
compiling should be done by experienced 'repository level' compilers.

The fact that there are a number of (so many?) different repositories
means (at least to me) that the number of different repo/s shouldn't
'recklessly' increase.

There's a LOT of 'stuff' in such as the Debian repo/s and Canonical goes
to a fair amount of trouble from Debian repo/s to Ub's and then all of
those .ppa people expand that.

That link you gave about soundware fluidsynth leads to a discussion of
using several different distro/s, Devuan, Artix, Slackware, & openSuse
to do soundware 'exercises' (and the 'bumps in the road' he encountered)

The fluidsynth github page says there is a built package for Gentoo,
Ub/Deb, Arch, Fedora, openSuse and even Mac. Not slackware.

Also, fluidsynth *seems* to have a pretty significant page about
building at https://github.com/FluidSynth/fluidsynth/wiki/BuildingWithCMake

... however, nowhere in that do I see anything even mentioned about jack
or its absence, which is what your link was asking/answering.

--
Mike Easter

[J.O. Aho]

On 17/06/2022 13.43, bad sector wrote:
>
> Two reasons why I (probably no alone) think my need for increased compiling from source is going to rise: the increase in security threats

This is the reason to not compile things yourself, as you will not have
all the resources to know about all vulnerabilities, some are known by
developers and distros maintainers but not by the public, these bugs are
generally the worst ones and kept secret until there is a fix that is
then released quietly and when the majority of people have had the
chance to update to the new safe version the vulnerability is disclosed.

> and the rising complexity of some of my user-level 'apps'.

The more complex, the better you let those who has the building
automated do the job, that way it's done right each time.

> I _discovered_ that fluidsynth had to be compiled with jack ALREADY installed for it to have jack support.

Yes, you need the libraries and headers to be able to build something
depending/using them, this is nothing new, this been how things have
been since the time of the first dynamically linked libraries.


Avoid building yourself, if you need to build, use the package for your
distro as base and do the modification in the build instructions (for
example in the spec file for rpm) if you need a feature that ain't built
in the distros version, at least you get all the original build
dependencies fixed and you get a package that you can easily install on
other machines with the same distro.


--

//Aho

[bad sector]

On 6/17/22 15:58, Mike Easter wrote:

> bad sector wrote:

> That link you gave about soundware fluidsynth leads to a discussion
> of using several different distro/s, Devuan, Artix, Slackware, &
> openSuse to do soundware 'exercises' (and the 'bumps in the road' he
> encountered)

the he is me :-)

The objective is to get to the bottom of issues revolving around MY
sound-studio-with-rosegarden sessions, before writing a help document.

> The fluidsynth github page says there is a built package for Gentoo,
> Ub/Deb, Arch, Fedora, openSuse and even Mac. Not slackware.
>
> Also, fluidsynth *seems* to have a pretty significant page about
> building at
> https://github.com/FluidSynth/fluidsynth/wiki/BuildingWithCMake
>
> ... however, nowhere in that do I see anything even mentioned about
> jack or its absence, which is what your link was asking/answering.

I haven't looked at that one yet, but the issue did get solved by following the code given by chris in linuxquestions.org

I just updated the page and as far as Slackware is concerned only a Yoshimi issue remains open (I'm very happy about that!). It looks like with this alone my go-to system for guitar/midi sessions has just changed from Suse to Slackware.

[bad sector]

On 6/17/22 13:11, Paul wrote:
> On 6/17/2022 7:43 AM, bad sector wrote:
>>
>> Two reasons why I (probably no alone) think my need for increased compiling from source is going to rise: the increase in security threats and the rising complexity of some of my user-level 'apps'. The security aspect needs no intro, the other one I just came across the other day when I _discovered_ that fluidsynth had to be compiled with jack ALREADY installed for it to have jack support.
>>
>> https://www.linuxquestions.org/questions/slackware-14/help-me-help-midiware-docu-shop-4175713408/
>>
>> The traditional way to compile used to be
>>
>> ./configure
>> make
>> make install (as root)
>>
>> I think I am not alone in this, I'd like to ask devs to try to stick to the above instructions but in all cases to clearly document the required procedure so that non-programmers might be able to read their way through it.
>>
>> TIA
>
> The stuff I've built lately, NONE of it worked like that :-/
>
> And when people deliver source, there is no longer a
> courtesy INSTALL with that style of recipe inside.
> Instead, the user is supposed to recognize a pattern
> in the 40 disparate configuration files in the main
> directory and conclude "oh, this could be a cmake".
> "Or maybe it's a mach with ranch dressing". It really
> is pathetic.

Yeah, and you know what? As with advancing age my needs for a computer (at all) reduce from perl programming to nothing but music and youtube videos, a Mac is starting to look better and better and that's he kind of change the Linux world needs like a hole in the head. But there you have it, the devs lay out the road!

> Even at the peak of ./configure expressive power, only
> a few developers provided good feedback to the "operator"
> as to what optional stuff was not going to be included.
> It's an art doing those.
>
> Just as some genius developers (subject matter experts),
> could not handle argc and argv if their lives depended on it.
> They had some great code, but the user could not get the
> benefit of most of it, because the command line
> invocation was so silly (did not follow accepted convention).
>
> And please, don't give me more of this "my source is my
> documentation" bullshit :-)

always thought so myself

> If it's not apparent how
> many build environments are buried in your tree, it could
> take absolutely-freaking-forever to figure it out. Some
> people even leave makefiles in the thing, that don't
> belong there. If there is detritus in the tree
> (developer droppings), they just leave it.
>
>    Paul

The last time I compiled rosegarden was about 10 years ago, now even the devs suggest to use the distro package instead. I actually tried yesterday in desperation, it bombed after the second keystroke. So then what happens to what Linux was in the beginning, when you would compile even your own kernel? That's something I tried only once in another life :-)

[bad sector]

Thanks, I mention security only as an observation, personally I have no interest in it. But the idea of modding existing packages may be something to look at later (never been past compiling i.e. on the upside of 'building' if I understand what that is correctly.

[Mike Easter]

Mike Easter wrote:
> Also, fluidsynth *seems* to have a pretty significant page about
> building at
> https://github.com/FluidSynth/fluidsynth/wiki/BuildingWithCMake
>
> ... however, nowhere in that do I see anything even mentioned about
> jack or its absence, which is what your link was asking/answering.

https://github.com/FluidSynth/fluidsynth/wiki/Audio-Drivers

> FluidSynth supports a large range of audio drivers across many
> platforms. Below is a table of all implemented audio drivers and some
> additional information for each driver.
>
> Please note that the audio drivers available in your version of
> FluidSynth not only depend on your platform and FluidSynth version,
> but also on which driver libraries where available during
> compilation.

id - Name - Platforms - Multi-Channel Output
jack - Jack - Linux, Windows - Yes

--
Mike Easter