build: Require libglad.la only when needed.

For the automake build its better to only depend on libglad.la when needed instead of always even when its not needed.

I noticed this because I only build a few make targets, incidentally none of these need libglad (i.e. make -C src/demos gears).

To identify these I used these two shell snippets, the first to add missing LDADD lines and the second to identify unneeded lines.

for i in $(grep -il glad *.c); do
  file=$(echo "$i" | tr - _)
  if ! grep -q ^"${file%.*}"_LDADD Makefile.am; then
    echo "${file%.*}_LDADD = ../glad/libglad.la" >> Makefile.am
  fi
done

sed -n '/_PROGRAMS/,/^$/p' Makefile.am > /tmp/_tmpfile

for i in $(grep -il glad *.c); do
  file=$(echo "$i" | tr - _)
  n1=$(grep ${i%.*} /tmp/_tmpfile | wc -l)
  n2=$(grep ${file%.*}_LDADD Makefile.am | wc -l)
  n=$(($n1+$n2))
  if [ $n -lt 2 ] && [ $n -gt 0 ]; then
    echo $i
  fi
done

changed target branch from master to main

@jrfonseca: This seems like a good idea to me, but since you did the GLAD change, maybe you could give this a proper review?

Thanks @kusma.

The changes are specific to automake for which I don't have much expertise / stake at. They look reasonable AFAICT. It does require a bit more of hand-typing linking GLAD test by test, but if this is net positive for automake users, it sounds fine by me.

Acked-by: Jose Fonseca <jfonseca@vmware.com>

Actually, thinking about this a bit more, I'm not so sure it's a good idea, simply because it's so verbose.

We're internally building GLAD, so what's the problem in depending on it? We don't do the same for the util code, for instance, so why do we need this for GLAD?

How about use epoxy instead?

That's tangential topic at best. This MR is more about autotools than glad itself. There's nothing wrong with glad, or anything that needs fixing. And if we had epoxy, a similar LDADD MR could exist, just s/glad/epoxy/.

If you want to know why not epoxy, you can refer to !23 (comment 571060)

Regarding this MR, I believe there's not enough merit to proceed: there doesn't seem to make sense on its own, and much less sense given @kusma's work to migrate away from autotools to meson. FWIW, I vote for NAK'ing.

In retrospect I agree that this is overly verbose. Although I still like the idea of only linking dependencies when they are needed. I am wondering if inverting the logic would be cleaner? Enable glad/epoxy for everything and then disable it for individual demos that don't need it.

I honestly don't understand what good that does. If you're linking to a library but don't end up using any of the symbols, you don't get any additional code in your executable. Sure, it might take slightly longer to link, but if we're optimizing the build, I'm sure there's much better places to start...

Now that this build system is deprecated, I don't think there's any point in doing this. So let's close this MR.

closed

Now that this build system is deprecated

I doubt it would make a difference now given this ship has sailed, but I want to point out that meson is a serious downgrade to autotools. The meson devs also have ignored almost every single issue I have reported so I doubt this will change.