Chris Bagwell wrote:
Hi,
> So I think its safe to say that you've had some sort of bad experience
> with some part of the autofoo chain in the past and have settle on
Not inside SANE. The most painful experience we've had here was
switching to modern autofoo versions that required an updated
Olaf Meeuwissen wrote:
Hi,
> Acknowledged. It may even be a better approach as several Linux
> distributions have a habit of running autoreconf --force before that
> build (and for a good reason). Putting the "hack" in configure makes
> at least sure they pick up on it.
"well deserved" :)
>
Julien BLACHE writes:
> Olaf Meeuwissen wrote:
>
> Hi,
>
>> Not doing so will make for a lot of big commits.
>
> And? What's the point? As long as the build system updates are
> self-contained and not mixed with other changes in the tree, we
> couldn't care less.
My full point was:
Although
Julien BLACHE wrote:
>> autofoo one has to know. As for the amount of pain involved, I can
>> only think of the time it takes. Julien mentions versioning issues
>> and broken deployment but I have little experience with that.
>>
>
> You obviously never had to work with broken libtool version
On Tuesday 20 January 2009, Olaf Meeuwissen wrote:
> >> autofoo one has to know. As for the amount of pain involved, I can
> >> only think of the time it takes. Julien mentions versioning issues
> >> and broken deployment but I have little experience with that.
> >
> > You obviously never had to
Chris Bagwell writes:
> On 1/18/2009 8:50 PM, Olaf Meeuwissen wrote:
>> See also,
>> http://www.gnu.org/software/gettext/manual/html_node/Files-under-CVS.html#Files-under-CVS.
>>
>>
> Agree with all your comments... Also, here is similar link from
> Automake that describes cvs issues in a li
Chris Bagwell writes:
> On 1/17/2009 3:20 AM, Julien BLACHE wrote:
>> Chris Bagwell wrote:
>>
>>> I've not seen this discussed in mailing list archive. Is there any past
>>> discussions?
>>
>> We leave autotools files in CVS because:
>> - it's a pain to regenerate them
>> - developers don't
Olaf Meeuwissen wrote:
Hi,
> Not doing so will make for a lot of big commits.
And? What's the point? As long as the build system updates are
self-contained and not mixed with other changes in the tree, we
couldn't care less.
> As we also discussed maintaining our changes to ltmain.sh as a patc
On 1/18/2009 8:50 PM, Olaf Meeuwissen wrote:
> See also,
> http://www.gnu.org/software/gettext/manual/html_node/Files-under-CVS.html#Files-under-CVS.
>
>
Agree with all your comments... Also, here is similar link from Automake
that describes cvs issues in a little more detail.
http://sourcew
On 1/17/2009 4:21 AM, Julien BLACHE wrote:
> Chris Bagwell wrote:
>
>
>> * Autotools not required, as long as developer is not modifying configure.in
>>
>
> While speaking of configure.in... it could use a good cleanup as
> you've probably seen, and while doing so it could also avoid tes
On 1/17/2009 3:20 AM, Julien BLACHE wrote:
> Chris Bagwell wrote:
>
> Hi,
>
>
>> I've not seen this discussed in mailing list archive. Is there any past
>> discussions?
>>
>
> We leave autotools files in CVS because:
> - it's a pain to regenerate them
> - developers don't always kno
Chris Bagwell wrote:
> * Autotools not required, as long as developer is not modifying configure.in
While speaking of configure.in... it could use a good cleanup as
you've probably seen, and while doing so it could also avoid testing
for freebsd/beos/osx things when running on Linux and vice-ver
Chris Bagwell wrote:
Hi,
> I've not seen this discussed in mailing list archive. Is there any past
> discussions?
We leave autotools files in CVS because:
- it's a pain to regenerate them
- developers don't always know autofoo
- distributions ship broken version of the autotools routinely
Hi all,
I've not seen this discussed in mailing list archive. Is there any past
discussions?
Its pretty common practice (but not 100%) that projects using autotools
to not check in files generated by autoconf/autoreconf into
CVS/git/etc. Currently, the sane project falls into the camp that t
14 matches
Mail list logo
