On Apr 15, 2021, at 11:23 AM, Paul Smith wrote:
>
> On Thu, 2021-04-15 at 08:33 -0500, Laurence Marks wrote:
>> there should be a way to autoupdate autoXYZ files for each system
autoreconf? https://linux.die.net/man/1/autoreconf
>> without user intervention.
Post-checkout hooks? https://gi
Hi Laurence,
from what I can see, you are trying to solve an issue outside the scope
autotools, which are AFAIK used in two contexts successfully:
1. users are provided a combination of source program and autotools
generated files, and, unless they want to change the build system
itself, hav
On Thu, 2021-04-15 at 08:33 -0500, Laurence Marks wrote:
> In the same way as autoXZY sets up Makefiles in an OS independent
> fashion, there should be a way to autoupdate autoXYZ files for each
> system without user intervention. (I don't mean automake itself or
> similar, I do mean only the local
As you say, it has files generated by autotools in a cvs (anonymous), so
when checking out there is a clash.
---
The software is at http://www.numis.northwestern.edu/Software/, mainly edm
& semper-7.0beta. They are both old, not so great but I still use them
every year or so for teaching, and ther
Hi Laurence,
On 15/4/21 6:35 am, Bob Friesenhahn wrote:
Most problems seem to stem from packages providing the generated files
from Autoconf, Automake, and libtool so that end users don't need to
have the tools available.
It will be easier for people here to help if you provide a bit more
in
On Thu, 15 Apr 2021, Laurence Marks wrote:
In the same way as autoXZY sets up Makefiles in an OS independent fashion,
there should be a way to autoupdate autoXYZ files for each system without
user intervention. (I don't mean automake itself or similar, I do mean only
the local files.) In an idea
Unfortunately things are not consistent, and in general have not been for
some time. It all depends upon which version has been installed which is
sometimes (often) beyond the control/competence of users. Even someone who
is moderately competent can have problems. For instance, on my laptop I
have
On Wed, 14 Apr 2021, Laurence Marks wrote:
It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2
versus 2.4.6 (for instance, those are just invented numbers). In many cases
aclocal, libtool, ltmain.sh and maybe a few others do not work if they were
created with a different autoX
It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2
versus 2.4.6 (for instance, those are just invented numbers). In many cases
aclocal, libtool, ltmain.sh and maybe a few others do not work if they were
created with a different autoXYZ version than is on the computer where they
On Wed, 14 Apr 2021, Laurence Marks wrote:
I have some software which has been "fine" for about 15 years, with one
exception: every 6-12 months or so when I (or students/others) compile it
we run into version problems. The typical ones are version mismatch between
libtool and/or aclocal (called
Hi Laurence - sorry, but I can't imagine how to automatically correct
version mismatches. The possible problems are both unpredictable and
endless, seems to me. Maybe others here have some more useful
idea. --best, karl.
I have some software which has been "fine" for about 15 years, with one
exception: every 6-12 months or so when I (or students/others) compile it
we run into version problems. The typical ones are version mismatch between
libtool and/or aclocal (called from libtool). While I can futze around with
l
12 matches
Mail list logo
