----- Original Message -----
> From: [email protected]
> To: "Jan Stancek" <[email protected]>
> Cc: [email protected]
> Sent: Tuesday, 30 September, 2014 10:49:17 AM
> Subject: Re: [LTP] [PATCH v2] ldd01: remove all -m32/-m64 logic
> > +top_srcdir ?= ../../../../..
> > +
> > +include $(top_srcdir)/include/mk/env_pre.mk
> > +
> > +CPPFLAGS += -fpic
> > +
> > +INSTALL_TARGETS := ldd*.so lddfile.out
> > +
> > +LDD_C_FILES := $(wildcard $(abs_srcdir)/lddfile*.c)
> > +LDD_SO_FILES := $(patsubst
> > $(abs_srcdir)/%.c,%.obj.so,$(LDD_C_FILES))
> > +MAKE_TARGETS := lddfile.out
> > +CLEAN_TARGETS += *.obj $(LDD_SO_FILES)
> > +
> > +%.obj: %.o
> > + mv $^ $@
> > +
> > +%.obj.so: %.obj
> > + $(CC) $(CFLAGS) -shared -o $@ $^
>
> Is the obj added here in order to avoid standard rules we have for
> building binaries? Otherwise it looks useless to me.
Agreed, I'll remove it.
> We should not need the TCdat and CC anymore.
Agreed, I'll remove it.
>
> > -TCtmp=${TCtmp:-/tmp/ldd01-$$}
> >
> > -do_cleanup()
> > -{
> > - rm -rf $TCtmp
> > -}
> > -
> > -do_setup()
> > +do_test()
> > {
> > - mkdir $TCtmp
> > -
> > - # Check for ppc64 architecture or x86_64 architecture
> > - if uname -a | grep -iq powerpc; then
> > - file lddfile1.obj | grep 64-bit >/dev/null 2>&1
> > - if [ $? -eq 0 ]; then
> > - CFLAGS="-m64"
> > - fi
> > - elif uname -a | grep -iq x86_64; then
> > - file lddfile1.obj | grep 32-bit >/dev/null 2>&1
> > - if [ $? -eq 0 ]; then
> > - CFLAGS="-m32"
> > - fi
> > + if [ -z "$LTPROOT" ]; then
> > + export LD_LIBRARY_PATH=./datafiles:$LD_LIBRARY_PATH
> > + LDDTESTFILE="./datafiles/lddfile.out"
> > + else
> > + export
> > LD_LIBRARY_PATH=$LTPROOT/testcases/data/ldd01:$LD_LIBRARY_PATH
> > + LDDTESTFILE="$LTPROOT/testcases/data/ldd01/lddfile.out"
> > fi
>
> Here you are expecting that the testcase is executed with the working
> directory is LTPROOT, which may not be the case if somebody adds
> tst_tmpdir to the test. Let's use
> LD_LIBRARY_PATH="$LTPROOT/datafiles/:$LD_LIBRARY_PATH" instead.
>
> Otherwise the auto detection is really nice to have. Maybe we can do
> this even better and add a LTP_DATAROOT to test.sh which will
> automatically point to a directory with the datafiles. If we define that
> datafiles must be stored in subdirectory named 'datafiles' we can just
> set the variable in test.sh and then do just:
>
> export LD_LIBRARY_PATH="$LTP_DATAROOT:$LD_LIBRARY_PATH"
>
> in the testcase. What do you think?
I think it's good idea - then we can avoid doing that in every testcase.
Is this close to what you had in mind?
diff --git a/doc/test-writing-guidelines.txt b/doc/test-writing-guidelines.txt
index a59fdd9..d157419 100644
--- a/doc/test-writing-guidelines.txt
+++ b/doc/test-writing-guidelines.txt
@@ -181,10 +181,14 @@ IMPORTANT: The runtest files should have one entry per a
test. Creating a
^^^^^^^^^^^^^^^
If your test needs datafiles to work, these should be generally put into a
-subdirectory named test name ('TCID' see below) and install it into the
-'testcases/data/' directory. The datafiles can be accessed as
-'$LTPROOT/testcases/data/TCID/...'. See
-'testcases/network/rpc/basic_tests/rpc01/' for example.
+subdirectory named "datafiles" and installed into the 'testcases/data/$TCID'
+directory.
+
+If your test includes "test.sh" you can use LTP_DATAROOT
+ '$LTP_DATAROOT/...'
+The datafiles can also be accessed as
+ '$LTPROOT/testcases/data/$TCID/...'
+See 'testcases/network/rpc/basic_tests/rpc01/' for example.
NOTE: There may be some convenience interface added later.
diff --git a/testcases/lib/test.sh b/testcases/lib/test.sh
index 10282f4..49e3d83 100644
--- a/testcases/lib/test.sh
+++ b/testcases/lib/test.sh
@@ -144,4 +144,8 @@ export TST_TOTAL="$TST_TOTAL"
# Setup LTPROOT, default to current directory if not set
if [ -z "$LTPROOT" ]; then
export LTPROOT="$PWD"
+ export LTP_DATAROOT="$LTPROOT/datafiles"
+else
+ export LTP_DATAROOT="$LTPROOT/testcases/data/$TCID"
fi
+
Regards,
Jan
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
