Oh, absolutely, python is a nonstarter for an autotools replacement.
Autotools is/was great because it worked everywhere, even during early
bootstrap where all you have is shell, basic shell utilities, and a C
compiler.
Python doesn't, and never will.
The C ports of meson and ninja could potentia
On 15 Feb 2022 20:25, Jacob Bachmeyer wrote:
> Dan Kegel wrote:
> > Meson is a candidate for such a next-gen config system. It is in python,
> > which does not quite qualify as usable during early uplift/bootstrap, but
> > there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
>
> *P
On 15 Feb 2022 08:29, Bob Friesenhahn wrote:
> A problem with xargs is that without using the GNU -O or --null
> argument and null-terminated arguments, file names containing spaces
> won't be handled properly. File names containing spaces is an issue
> for Autotools in general. This is again
On Tue, Feb 15, 2022 at 6:01 PM Bob Friesenhahn
wrote:
> The people who tell me it is more portable are very interested in
> targeting Microsoft Windows.
Introduce them to mingw-w64.sf.net + msys2 :) I heard good things
about those :P
> The "Makefiles" that Cmake generates are self-referential
Dan Kegel wrote:
Meson is a candidate for such a next-gen config system. It is in python,
which does not quite qualify as usable during early uplift/bootstrap, but
there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
*Please* do not introduce a dependency on Python; they do n
On Tue, 2022-02-15 at 16:59 -0600, Bob Friesenhahn wrote:
> The people who tell me it is more portable are very interested in
> targeting Microsoft Windows.
Unsurprising :).
Just to be clear, cmake can't/won't help you write programs that are
portable to Windows. If you are targeting the W32 sy
On Tue, 15 Feb 2022, Paul Smith wrote:
On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:
I have been told by several people (who have much more self-esteem
than me) that a build tool called 'cmake' is far more portable than
Autotools so maybe we should make support for 32 year old syste
On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:
> I have been told by several people (who have much more self-esteem
> than me) that a build tool called 'cmake' is far more portable than
> Autotools so maybe we should make support for 32 year old systems
> cmake's responsibility?
That
It it really expected that Autotools should support 32 year old
systems?
This feels counter-productive to me.
I have been told by several people (who have much more self-esteem
than me) that a build tool called 'cmake' is far more portable than
Autotools so maybe we should make support for 32
On 2022-02-14, Mike Frysinger wrote:
> context: https://bugs.gnu.org/53340
>
> how portable is xargs ? like, beyond POSIX, as autoconf & automake both
> support non-POSIX compliant systems. i want to use it in its simplest
> form: `echo $var | xargs rm -f`.
As far as I can tell xargs was introd
# egg...@cs.ucla.edu / 2022-02-14 19:53:17 -0800:
> On 2/14/22 19:45, Mike Frysinger wrote:
> > how portable is xargs ?
>
> It can be a porting problem, unfortunately. There are several corner
> cases that various implementations don't get right. I expect this is why
> the GNU Coding Standards e
If the goal is to limit command line length while maintaining or increasing
the number of files passed to various compilation tools, it may be worth
writing object lists to files to be passed as command scripts - in cases
where the tool supports it. Obviously whether the majority of tools support
c
On Mon, 14 Feb 2022, Mike Frysinger wrote:
On 14 Feb 2022 19:53, Paul Eggert wrote:
On 2/14/22 19:45, Mike Frysinger wrote:
how portable is xargs ?
It can be a porting problem, unfortunately. There are several corner
cases that various implementations don't get right. I expect this is why
th
On Tue, 15 Feb 2022, Jan Engelhardt wrote:
On Tuesday 2022-02-15 07:16, Daniel Herring wrote:
Maybe a next-generation configuration tool should start by defining interfaces
for user interactions and build tools. This would allow CLI and easy GUI and
IDE users, integration with multiple build
On Tuesday 2022-02-15 07:16, Daniel Herring wrote:
>
> Maybe a next-generation configuration tool should start by defining interfaces
> for user interactions and build tools. This would allow CLI and easy GUI and
> IDE users, integration with multiple build systems, static and dynamic
> probing
Meson is a candidate for such a next-gen config system. It is in python,
which does not quite qualify as usable during early uplift/bootstrap, but
there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
In the meantime, I agree that find is more portable than cards ;-)
- Dan
Daniel
Hi Mike,
It often makes sense to change a project that uses Autotools rather than
modifying the Autotools. Can this argument-splitting behavior be
documented as expected? Are no workarounds available?
Replacing "overly fancy but proven shell script" with "dependency on a new
tool" may repl
On 2/14/22 20:03, Mike Frysinger wrote:
are the corner cases known ?
I don't know of a catalog, no.
These days you might have better luck with "find ... -exec ... {} +".
Although standardized more recently than xargs, my vague impression is
that there's less variation among implementations.
On 14 Feb 2022 19:53, Paul Eggert wrote:
> On 2/14/22 19:45, Mike Frysinger wrote:
> > how portable is xargs ?
>
> It can be a porting problem, unfortunately. There are several corner
> cases that various implementations don't get right. I expect this is why
> the GNU Coding Standards exclude xa
On 2/14/22 19:45, Mike Frysinger wrote:
how portable is xargs ?
It can be a porting problem, unfortunately. There are several corner
cases that various implementations don't get right. I expect this is why
the GNU Coding Standards exclude xargs from the list of programs that
'configure' and
20 matches
Mail list logo
