All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2009-06-01  4:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-28  9:24 [LTP] Installing outside LTP source Michal Simek
     [not found] ` <4A1E5847.6030807-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org>
2009-05-29 12:54   ` Subrata Modak
2009-05-29 12:54     ` [LTP] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.