From: Mike Frysinger <vapier@gentoo.org>
To: michal.simek@petalogix.com
Cc: LTP <ltp-list@lists.sourceforge.net>, Jiri Palecek <jpalecek@web.de>
Subject: Re: [LTP] Installing outside LTP source
Date: Mon, 1 Jun 2009 00:44:47 -0400 [thread overview]
Message-ID: <200906010044.48635.vapier@gentoo.org> (raw)
In-Reply-To: <4A22DA33.5050601@petalogix.com>
[-- Attachment #1.1: Type: text/plain, Size: 3775 bytes --]
On Sunday 31 May 2009 15:27:47 Michal Simek wrote:
> Mike Frysinger wrote:
> > On Saturday 30 May 2009 10:28:48 Michal Simek wrote:
> >> Mike Frysinger wrote:
> >>> On Thursday 28 May 2009 05:24:23 Michal Simek wrote:
> >>>> I would to ask you if someone works or worked on moving LTP to Kbuild.
> >>>
> >>> the Subject line doesnt really seem to line up with this question.
> >>> what exactly do you want to do and why do you think Kbuild is the
> >>> solution ? saying "let's switch to Kbuild!" without any rhyme or reason
> >>> sounds like a lot of work for no gain.
> >>
> >> I wanted to wrote two emails instead of one - that's why was there 2
> >> different things.
> >> 1. disable compilation "verbose" mode and turn on it with V=1.
> >
> > meh. `make -s` seems to work fine enough for me. most people arent
> > reviewing the output for warnings and similar issues, so i dont really
> > see much point of having quiet output in LTP.
>
> People don't do it because that warnings are hidden in huge log. It will
> be good to run sparse too.
i dont think sparse is applicable. it is largely geared towards the policies
employed in the kernel.
> >> 2. Move all binaries outside of LTP source code O=/path
> >
> > you mean out-of-tree compilation. you can use lndir to get the same
> > functionality, but it isnt really an optimal method.
> >
> >> 3. I use only some parts of LTP for my testing and it will be good to
> >> enable/disable just tests which you want to use.
> >
> > you can run `make` in only the dirs you care about. how deep do you
> > actually want to get ? having Kconfig entries for every single test
> > (i.e. kernel/syscalls/{getsid,pipe}0{1,2} .....) is crazy.
>
> Yes, I agree that make no sense to add all syscalls test for example to
> Kconfig but I can imagine tests for noMMU as are currently wrote in
> Makefile.
sounds a bit arbitrary. you and i may be interested in nommu, but what about
other classifications of things people are interested in ? that'd lead to
messy kbuild files where tests are arbitrary grouped and the resulting build
system would be just as bad.
> For example will be good for all to know why are some tests exclude for
> noMMU.
i dont see how that's relevant to kbuild. that info should be documented
regardless in the test case itself.
> Maybe any handling for older glibc with missing some syscalls to prevent
> build failure.
that is already handled by autoconf/autoheader, plus kconfig/kbuild has no
functionality at all to address these issues.
> Setup global cflags and cross compiler.
already handled by autoconf. integrating into kconfig would be reinventing
the wheel for no appreciable gain.
> If you look to runtest for testing description, make sense to me have
> all that filenames as Kconfig option and enable/disable that tests.
ive never used/looked at runtest, sorry
> >> 4. If is possible clean all Makefiles
> >
> > dont really know what that means
>
> this point depended on descriptions below. I think we talked about once
> in past.
>
> There are a lot of additions like CFLAGS, LDLIBS.
> CFLAGS += -I../../../../include -Wall
> LDLIBS += -L../../../../lib -lltp
>
> I think that install and clean parts could be possible to clean too and
> have Makefiles with
> one or two lines like test-y +=test_name
>
> Is it possible to do with Kbuild? That the same question as I had in
> previous email.
that can be done right now without any other issue. create a top level .mk
file, define topdir in the specific Makefile, and then include it.
topdir = ../../../..
include $(topdir)/common.mk
then the common.mk can setup common flags or create automatic clean targets
-mike
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 444 bytes --]
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
[-- Attachment #3: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2009-06-01 4:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-28 9:24 [LTP] Installing outside LTP source Michal Simek
2009-05-29 12:54 ` Subrata Modak
2009-05-29 13:12 ` Mike Frysinger
2009-05-30 14:28 ` Michal Simek
2009-05-30 22:16 ` Mike Frysinger
2009-05-31 19:27 ` Michal Simek
2009-06-01 4:44 ` Mike Frysinger [this message]
2009-06-01 7:13 ` Michal Simek
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=200906010044.48635.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=jpalecek@web.de \
--cc=ltp-list@lists.sourceforge.net \
--cc=michal.simek@petalogix.com \
/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