On Thu, 13 May 2021, FOURNIER Yvan wrote:
Hi Karl,
Regarding the possible addition of a libtool option to ignore .la
files, I would need to take a deeper look into how libtool works (I
have only scratched the surface and experimented with it as a "black
box" so far, but If I do get around to
find some time, though it might wait several
weeks. If C++ precompiled headers use the same logic, it will add additional
motivation.
Best regards,
Yvan
De : k...@freefriends.org
Envoyé : jeudi 13 mai 2021 03:20
À : FOURNIER Yvan
Cc : automake@gnu.o
Hi Yvan - sorry for the delayed reply.
While configure/automale/libtool seem to be designed to work together,
Yes, they were. It seems your major issues are with libtool. I can
(uselessly) sympathize, but unfortunately that's all I can do. Libtool
is currently unmaintained (according to GNU r
On Thu, 6 May 2021, Andy Tai wrote:
a general question: would a rewrite in Python or some other language,
to keep the same functionality as the current implementation, a viable
goal, or that would not be a productive thing to do?
There are several major aspects of Automake. One is the use of
a general question: would a rewrite in Python or some other language,
to keep the same functionality as the current implementation, a viable
goal, or that would not be a productive thing to do?
On Thu, May 6, 2021 at 1:44 PM Bob Friesenhahn
wrote:
>
> On Thu, 6 May 2021, Karl Berry wrote:
> >
>
On Thu, May 6, 2021 at 4:44 PM Bob Friesenhahn
wrote:
>
> On Thu, 6 May 2021, Karl Berry wrote:
> >
> > (*) https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
> > So far the response has been nil.
>
> I don't recall seeing that email. I did see an email thread regarding
> Autoconf
On Thu, 6 May 2021, Karl Berry wrote:
(*) https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
So far the response has been nil.
I don't recall seeing that email. I did see an email thread regarding
Autoconf which immediately became a lot of "need to support this soon"
and "wou
I think automake really needs to support this soon.
Sounds reasonable to me, but to be clear, Automake will only support
things that volunteers care enough about to actually dig into the
code and write patches for. New developers/maintainers are needed.
As I previously explained(*) / pleaded,
On Mon, May 3, 2021 at 5:34 AM Thomas Jahns wrote:
> > - Our code is a mix of Fortran and C, with a bit of C++. Automake still
> > deos not support Fortran 90-type module dependencies, so we have to manage
> > manual dependencies in one of our Makefile.am's. More modern systems handle
> > Fort
On Sun, 2021-05-02 at 17:49 +, FOURNIER Yvan wrote:
> - When using Gettext, "make update-po" modifies code in the source
> tree based on a command in the build tree. When using separate source
> and build trees, this is somewhat surprising, so having an equivalent
> command (not based on the ge
Hello,
some comments with a similar HPC background:
On 2021-05-02 19:49, FOURNIER Yvan wrote:
[...]
- it is very easy to find the configure options from a previous run at the top
of the config.log and config.status files, and then copy/past them so as to
generate an new build in a clean (empt
Hello,
Sorry for reacting a bit late to the January discussion about Autotool's future.
As a longtime user of the GNU Autotools for a large computational dynamics code
(code_saturne.org), here are a few hopefully constructive remarks about our
experience so far.
Sorry if my post is a bit lo
I'd just like to suggest that in the event of future significant
development on a new automake, or a revamped build system in whatever
way, that the new system not be called "autoconf" or "automake".
It seems inevitable to me that any such new system would have
incompatibilities with the old, and
On Tue, 2021-01-26 at 11:01 -0800, Andy Tai wrote:
> GNU Make integrates with guile. Maybe such extension can be
> done using guile for flexibility?
The problem is that hardly any standard distributions build GNU make
with Guile support enabled. If this was used basically it would end up
requir
GNU Make integrates with guile. Maybe such extension can be done
using guile for flexibility?
(ref:
https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html#Guile-Integration)
On Thu, Jan 21, 2021 at 12:11 PM Paul Eggert wrote:
>
> One possible way forward is to have an Autocon
As always, thanks for all your effort Zack!
I wanted to share some of my thoughts on Autoconf and friends. Maybe I
wrote too much.
For me the most important requirement of the GNU build system is that
it must be as straightforward as possible for novice users to build free
software packages from
> "Gavin" == Gavin Smith writes:
Gavin> I remember somebody was
Gavin> complaining about this page:
Gavin>
https://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html
Gavin> and asking what "maude" meant - it turned out it was the name of the
Gavin> dog or somet
On 1/21/21 8:01 AM, Zack Weinberg wrote:
I know that
at least one person has tried to write a set of GNU Make library files
intended to replace it altogether, but I've never seen anyone *finish*
that project. I'd very much like to see someone give that another go.
GNU Emacs never used Automake
My two cents:
the competing build systems, cmake, meson, have in their "features" (and
major motivation for their original development) of supporting Xcode and
Microsoft Visual Studio. Supporting for these seem to become necessary for
GNU Autotools to compete, even if these two may be outside of
Zack,
On Thu, Jan 21, 2021 at 9:12 AM Zack Weinberg wrote:
> On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote:
> > Now we've all had a while to recover from the long-awaited Autoconf
> > 2.70 release, I'd like to start a conversation about where the
> > Autotools in general might be going in
On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries. I don't t
On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote:
> Now we've all had a while to recover from the long-awaited Autoconf
> 2.70 release, I'd like to start a conversation about where the
> Autotools in general might be going in the future.
> Now we've all had a while to recover from the long-awa
On 21/1/21 9:15 am, Zack Weinberg wrote:
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the
On Wed, 2021-01-20 at 17:15 -0500, Zack Weinberg wrote:
> As a starting point, I wrote up a "strengths, weaknesses,
> opportunities, and threats" analysis for Autotools -- this is a
> standard project management technique, if you're not familiar with
> it, there's a nice writeup in the draft of the
* On 2021 20 Jan 17:33 -0600, Bob Friesenhahn wrote:
> Autotools is in great danger of becoming irrelevant, at least for new
> software development. A lot of people feel hostile toward it.
This is quite true.
As a co-maintainer of a library project that uses Autoconf, Automake,
and Libtool, I've
It seems better not to start another language. with already lack of
resources, that will further dilate available resources, and hard to
compete with other tools already us9ng Python's mature ecosystem
On Wed, Jan 20, 2021 at 3:32 PM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
>
> In
On Wed, 20 Jan 2021, Zack Weinberg wrote:
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do th
Thanks for writing all of this.
I'm writing from the perspective of a long-term user of the autotools.
A discussion like the one you have started will likely attract many
opinions. Some will be contradictory. However, somebody in the end
will have to decide.
The challenge seems to be to evolve th
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the work, but before
we worry about that I thin
29 matches
Mail list logo
