On Mon, May 14, 2012 at 12:25 PM, Anand Babu Periasamy <abperiasamy@xxxxxxxxx> wrote:
Not quite. That's the whole point of having a configure script in the first place - to detect the environment at build time. One who builds from source should not require to run autogen.sh, just configure should be sufficient. Since configure itself is a generated script, and can possibly have mistakes and requirements change (like the one being discussed), that's when autogen.sh must be used to re-generate configure script.
In this case however, the simplest approach would actually be to run autogen.sh till either:
a) we upgrade the release build machine to use newer aclocal macros
b) qualify geo-replication to work on python 3 and remove the check.
Emmanuel, since the problem is not going to be a long lasting one (either of the two should fix your problem), I suggest you find a solution local to you in the interim.
Even better, if someone can actually test and qualify geo-replication to work on python 3 it would ease solution "b" sooner.
Avati
On Mon, May 14, 2012 at 11:46 AM, Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote:Who ever builds from source is required to run autogen.sh to produce
> Kaleb S. KEITHLEY <kkeithle@xxxxxxxxxx> wrote:
>
>> > Well, my problem is that python 2.5, python 2.6 and python 2.7 are not
>> > detected by configure. One need to patch configure in order to build
>> > with python 2.x (x> 4) installed.
>>
>> Seems like it would be easier to get autoconf and automake from the
>> NetBSD packages and just run `./autogen.sh && ./configure`
>
> I prefer patching the configure script. Running autogen introduce build
> dependencies on perl just to substitute a string on a single line:
> that's overkill.
>
env specific configure and build files.
Not quite. That's the whole point of having a configure script in the first place - to detect the environment at build time. One who builds from source should not require to run autogen.sh, just configure should be sufficient. Since configure itself is a generated script, and can possibly have mistakes and requirements change (like the one being discussed), that's when autogen.sh must be used to re-generate configure script.
In this case however, the simplest approach would actually be to run autogen.sh till either:
a) we upgrade the release build machine to use newer aclocal macros
b) qualify geo-replication to work on python 3 and remove the check.
Emmanuel, since the problem is not going to be a long lasting one (either of the two should fix your problem), I suggest you find a solution local to you in the interim.
Even better, if someone can actually test and qualify geo-replication to work on python 3 it would ease solution "b" sooner.
Avati
