#367 configure: more options to disable unneeded stuff

[Carlo Bramini]

Hello, I'm wondering if you could accept to add few more extra options to configure.ac to disable some stuff that the user does not need or he may not not want to include into the binaries.
In my head, I have seen these ones:

--enable/disable-mpg123
--enable/disable-flac
--enable/disable-ogg

Something similar would be helpful also for people like me who has tried to build VICE for bare metal systems. Otherwise, you are forced to uninstall the libraries before configuring the build.

Sincerely.

[Pontus Berg]

On the same note, disable destination platforms not really required. Like
the pet, plus4 and others I never ever even started but which are built for
me one every run.

[gpz]

would you please stop that fullquoting please ;_;

you can build just one emulator already, use "make x64sc"

[Pontus Berg]

Den fre 7 aug. 2020 kl 14:02 skrev gpz gpz@users.sourceforge.net:

you can build just one emulator already, use "make x64sc" in revision
38350 at least.

Nope - didn't work. Make "x64sc" yielded an error.

make: *** [Makefile:933: x64] Fel 2

(That is "Error 2" in Swedish)

[compyx]

If I understand correctly, you want to be able to explicitly disable certain libraries configure automatically detects and tells VICE to use when found?

I agree this 'auto-detection' can be annoying. Took me a while to figure out how to get MP3 read/write support compiled in. Same goes for ffmpeg support, VICE checks for libavcodec, libavresample/libswresample etc, never managed to get configure to 'see' libavresample.

Since I appear to be the de-facto autohell maintainer, I'll have a look. But changing this configure behaviour might result in a few surprises, we'll see.

[compyx]

As for making only a few targets, and not all, that's another can of worms:

After make clean, and doing make $emu, I get this:

c1541:
    make[1]: *** No rule to make target '../src/lib/linenoise-ng/liblinenoiseng.a', needed by 'c1541'.  Stop.
x64, x64sc, x128:
    make[1]: *** No rule to make target 'libdatasette', needed by '$emu-all.  Stop.
vsid:
    make[1]: *** No rule to make target 'libdatasette', needed by 'vsid-all'.  Stop.

I gave up when VSID required 'libdatasette' (it doesn't). And even if you can get a separate emu binary to compile, the make install or make bindist targets will fail since they except all emus (x64 is configurable).

So I'd suggest making this a separate feature request.

[compyx]

Added --with/without-mpg123 to configure. Works for me on Debian. Please give it try.

[Carlo Bramini]

I updated the sources and I configured with "--without-mpg123" option.
After the build process completed, the final executables do not need anymore the presence of libmpg123.

[Carlo Bramini]

I have seen that you also added a "ogg-vorbis" option but, after this change, libFLAC cannot be used anymore, because you changed FLAC_PRESENT to "no" at global level.
Am I doing some mistakes or this is wrong?

[Greg King]

I have seen that you also added a "ogg-vorbis" option but, after this change, libFLAC cannot be used anymore, because you changed FLAC_PRESENT to "no" at global level.
Am I doing some mistakes or this is wrong?

It's a bug.

[compyx]

Yup, that was a bug, I probably wanted to add --with/without-flac in the same commit as the ogg-vorbis changes, but decided against it.

FLAC support is now always enabled when found as configure did previously (see r38354). I'll try to add --with/without-flac soon.

[compyx]

I've added --with/without-flac in r38355. Works on my Debian box.

[Carlo Bramini]

Hello, I tried the options and they seems to work fine.
By the way, perhaps you may consider to change "--with/without-ogg-vorbis" into just "--with/without-vorbis" because libogg is a dependency for both libFLAC and libvorbis, so using just "--without-ogg-vorbis" won't remove the need of libogg.
However, this is just a matter of naming, you can leave things as they are, if you like current name more.

[Pontus Berg]

Den tors 13 aug. 2020 kl 10:19 skrev Carlo Bramini carlo_bramini@users.sourceforge.net:

Hello, I tried the options and they seems to work fine.
By the way, perhaps you may consider to change "--with/without-ogg-vorbis"
into just "--with/without-vorbis" because libogg is a dependency for both
libFLAC and libvorbis, so using just "--without-ogg-vorbis" won't remove
the need of libogg.

Tried building under Windows but got errors. I had to disable vorbis and
flac in order to make it build.

[compyx]

Since you haven't provided any error messages, I'll assume this is a configure issue: if you don't want ogg/vorbis, flac or mpg123, use --without-vorbis --without-flac --without-mpg123. If you do want them, which is the default now, use:

pacman -S mingw-w64-x86_64-{libvorbis,flac,mpg123}

to install the required packages and their dependencies (replace 'x86_64' with 'i686' if compiling for 32-bit).

[Carlo Bramini]

Hello, I tried several configurations on Windows without problems.
I attached all results here as reference:

• no options
• --without vorbis
• --without-flac
• --without-mpg123
• --without-vorbis --without-flac --without-mpg123

So, I cannot really understand where the build problems could be.

[compyx]

Sounds reasonable to me, I've changed the switch to --with-vorbis in r38376.

[compyx]

Marking this 'fixed'. Works on Linux and Windows, most likely works on MacOS or *BSD.

[Carlo Bramini]

Great, just one more little thing: you left "--with/without-ogg-vorbis" in the summary.

[Pontus Berg]

Meanwhile, after some discussion on #vice-dev, I've changed the
--with/without behaviour of flac, mpg123 and ogg/vorbis to disable support
unless explicitly requested via --with.
I have also changed --with/without-lame to do the same, and a fixed a bug
where lame support would never be activated.

Is there a general principle of when something is --with/without and when
its --enable/disable? I think that has gotten to be quite confusing (even
if I understand it is a mess to change). I see that enable/disable is
sorted under "optional features" whereas and with/without is sorted under
"optional packages". I can't say I understand the distinction. (One
example: For sound, Lame is in one place and Flac in the other - go figure).

The GIF and JPEG screenshot driver selection now also behaves as above.
PNG seems like a candidate for explicitly disabling (--without) rather than
enabling. libpng16 is a hard dependency of Gtk3, so people building the
Gtk3 port will have it installed anyway. SDL is another matter of course.

There are still a lot of 'suprise compiling' issues, for example the sound
drivers for ALSA, Pulse, OSS and USS all will be enabled when found and
silently ignored when not found.
Use configure --help to see a list of --with/--enable and then check
configure.proto to see what I mean.

So, before I start hacking on this, I'd like to see some concensus on
which features should be enabled by default and which should be disabled by
default. It would also be good to know if we want any of this 'surprise
compiling' to remain.

IMHO (being one mere voice here): In general, apply the principle to
disable unless it's very common. This to make the payload as lightweight as
possible and to make compile as fast as possible.

Especially disable physical hardware such as Catweasel and HardSid. These
are rare in the wild.

My preference is PNG when I do screenshots, so I would enable that in my
builds.

Related 1:

And I would also like to be able to do (and have this as default);

--disable-xpet --disable-xplus4 --disable-xcbm2 --disable-xvic
--disable-vsid

Related 2:

The topology of the bindist is interesting.

Dirs "share" and "common" couldn't the content of these be merged under one
of them?

The biggest set of DLLs are under the bin folder, except for the one under
the lib older. Isn't "lib" a more logical home for support functions that
you cannot execute?

[gpz]

we can't change the dir structure - that's a result of how GTK works

[Pontus Berg]

Den tis 18 aug. 2020 kl 16:51 skrev gpz gpz@users.sourceforge.net:

we can't change the dir structure - that's a result of how GTK works

What about the below aspect?

--disable-xpet --disable-xplus4 --disable-xcbm2 --disable-xvic
--disable-vsid

[gpz]

too much hazzle for very little gain - you'd only save the linking stage

[compyx]

Reopening this ticket, we have some more optional things to handle better.

Meanwhile, after some discussion on #vice-dev, I've changed the --with/without behaviour of flac, mpg123 and ogg/vorbis to disable support unless explicitly requested via --with.
I have also changed --with/without-lame to do the same, and a fixed a bug where lame support would never be activated.

The GIF and JPEG screenshot driver selection now also behaves as above. PNG seems like a candidate for explicitly disabling (--without) rather than enabling. libpng16 is a hard dependency of Gtk3, so people building the Gtk3 port will have it installed anyway. SDL is another matter of course.

There are still a lot of 'suprise compiling' issues, for example the sound drivers for ALSA, Pulse, OSS and USS all will be enabled when found and silently ignored when not found.
Use configure --help to see a list of --with/--enable and then check configure.proto to see what I mean.

So, before I start hacking on this, I'd like to see some concensus on which features should be enabled by default and which should be disabled by default. It would also be good to know if we want any of this 'surprise compiling' to remain.