public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] syscalls/mallinfo2_01: Add a basic test for mallinfo2 when setting 2G size
Date: Wed, 16 Jun 2021 11:28:33 +0200	[thread overview]
Message-ID: <YMnEQSEAT5LTBSwN@yuki> (raw)
In-Reply-To: <da3974e4-76ee-1eee-b730-c49953c21120@jv-coder.de>

Hi!
> > BTW Cyril also suggested recently to drop out of tree support, because build
> > system dependencies are broken and fixing it would be much easier when
> > supporting only in tree build.
> Really? I got the feeling out-of-tree builds are becoming the new normal 
> and even complex pieces of software like the kernel, glibc and gcc are 
> able to be built out-of-tree or even enforce it.

The question here really if support of out-of-tree build is worth the
trouble. The problem is that the complexity it adds to the build system
is quite high. The way it's implemented in LTP the build system has to
work with absolute paths and you have to make sure you have the right
path to a file all the time and people are often confused by this. Also
it crashes and burns with cryptic error messages if you happen to have
characters interpreted by make in a directory name anywhere from the LTP
dir to the filesystems root (try adding : to a directory name for
instance). We used to have out-of-tree build broken for years, before we
set up a CI, and nobody complained. So considering all of this it may be
for the better to just get rid of it.

I'm not against out-of-tree build in principle but given that the way
it's implemented in LTP is subtly broken by design and that there does
not seem to be real users it does not make that much sense to keep it
maintained and spend any effort to keep it afloat.

> Maybe it is time to abandon autoconf/automake and switch to a better 
> build configuration systems like cmake instead of abandoning out-of-tree 
> builds.

I'm not againts this, the main problem is that this will take a
significant effort my guess is at least month to implement and and even
more to iron out all the corner cases. Also the choosen build systems
has to be generally available even on 10 years old system, but I guess
that cmake should classify easily here.

-- 
Cyril Hrubis
chrubis@suse.cz

      reply	other threads:[~2021-06-16  9:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07  7:30 [LTP] [PATCH] syscalls/mallinfo201: Add a basic test for mallinfo2 when setting 2G size Yang Xu
2021-05-25 10:56 ` Petr Vorel
2021-06-03  8:49   ` xuyang2018.jy
2021-06-03  9:44   ` [LTP] [PATCH v2] syscalls/mallinfo2_01: " Yang Xu
2021-06-16  6:51     ` Petr Vorel
2021-06-16  7:00       ` xuyang2018.jy
2021-06-16  7:03     ` Petr Vorel
2021-06-16  7:22       ` xuyang2018.jy
2021-06-16  8:51         ` Petr Vorel
2021-06-16  9:16       ` Joerg Vehlow
2021-06-16  9:28         ` Cyril Hrubis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMnEQSEAT5LTBSwN@yuki \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox