[libvirt] fix build failure with --disable-shared

[Jim Meyering]

Diego Elio “Flameeyes” Pettenò wrote:
> Il giorno gio, 07/01/2010 alle 23.03 +0100, Jim Meyering ha scritto:
>>
>> So your change forced all other users of --disable-shared
>> to also configure with --without-python, but did not inform them
>> of the new constraint.  BTW, it also rendered build instructions
>> in the FAQ invalid.
>
> I don't want to sound defensive, but I *do* feel attacked a bit here,
> and I don't think I made any mistake in my patch and suggestion.

No attack intended.  Merely explaining that your change does indeed
disrupt certain workflows.  Your change caused inconvenience for at
least two developers I know about, and I took it upon myself to resolve
the problem.  If you had announced that --disable-shared must henceforth
always be accompanied by --without-python, then that might have been ok,
modulo the FAQ requiring an update.

However, with the patch I posted, there's no need to change the FAQ
or any habits/scripts.

> If I did “force” users to configure properly,

The trouble is that your change had the undocumented side-effect of
forcing people to change their previously-working-for-their-needs scripts.

> it was because the build
> system was working on a wrong assumption before. Sorry if I made it
> known that there is a bug there.

Yes, you discovered a bug, and even sent in a patch.
I do appreciate that.

> As for the build instructions, I had to look them up now because I
> definitely hadn't looked at them; if I did, I would have et you know
> earlier about the fact that it's a *bad* advice to give.

Many programs can be configured with --disable-shared,
and most of libvirt is still usable when configured that way.
The bug was that the Python code was compiled in that case,
and could have ended up being installed.

However, do note that people familiar with the distribution guidelines
warning against installing statically-linked libraries would know to
avoid installing anything they had built that way.

> Why? Because I guess quite a few people interested in using libvirt
> would also be using virt-manager (especially since Daniel said that the
> XML files are not designed for user to edit, but for software to mangle)
> and that only works with proper Python bindings — and they are not
> generated with the suggested syntax in the FAQ.
>
> It actually can create quite a bad thing if the user tries to be smart
> and install the CVS (CVS? I thought it was developed in GIT) versions
> with make install after the configure, as the bindings and the
> virsh/libvirtd executables will be using very different libraries.
>
> Do I ask too much if next time, rather than noticing by chance that
> somebody wants to revert a change I proposed, you would reply to my own
> posting (which I watch more closely), letting me know it broke
> something? I'm pretty sure I can fix up things from there myself.

I've learned that it is usually more efficient to propose a patch than
to request one.  I proposed to revert your change, because from my
perspective it was obviously wrong.  At the same time, I requested more
information, because I assumed the change must have had more motivation
than I could find in the mailing list and commit log.

My proposing to revert your patch should not be taken as an insult or an
offense, but rather as part of a request for additional justification.
Once I had that, I was able to write a patch that solved both our
problems.  Just posted separately.