Re: [LTP] Installing outside LTP source

Mike Frysinger
2009-06-01T04:46:11Z

[-- 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 --]