On Sun, Apr 02, 2017 at 08:05:01AM -0400, Dan wrote:
Hi All,
To compile to a non-current version, I could download a tar ball, or switch
to an older branch in git, then do ./autogen.sh (or ./configure) && make
&& make install.
But for some purpose, I may want to compile to historical version easily
without redundantly downloading the source by using some magic flag
passed into either ./configure, ./autogen.sh, or make, e.g.:
$ ./configure --version=2.0, or
$ ./autogen.sh --version-git=1.0
Is that possible at all?
I haven't heard of any project ever that would do anything like this.
Is it that much more complicated to do:
git checkout v2.0.0; git clean -fxd; git submodule update
In most cases only the first command needs to be done anyway.
Related question, normally speaking, how to test back-compatibility
of a new patch, or do we need to test it at all?
Depends what you want to test. For some things it's enough to have a
rule, for example that you must not change API call numbers. For others
there are tests. If tests start failing, something went wrong. If you
have pdwtags installed, usually from the 'dwarves' package, there is
also test for remote structures (that they don't change), but mostly
people need to be careful while writing and reviewing code.
P.S., I was just reading v0.0.1 libvirt [1].
Funny fact, back then it was libvir! not libvirt. Hence the mailing
list address.
It is so nice to see there is, well, was nothing more then 2000 LOC
for C source code.
Well it also didn't do much, I presume. I can't say for sure, though,
I'm just guessing it from the documentation. Isn't this how all
projects start? =)
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list