|
Boost-Build : |
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2008-07-04 09:06:58
Hi Jurko !
On Friday 04 July 2008, Jurko Gospodnetiæ wrote:
> Hi Juergen.
> I'm not really sure what 'end-user functionality' is supposed to
> mean here or what is 'low level' about those Boost Build tests. They
> can contain any kind of build script, may use or expect any sort of
> configuration available on the system running the tests, may run the
> build and may analyze the build results... Not sure what more you
> need.
Well, most of them test basic functionality (like symlink.py) etc.
> You have an external runner (Python testing scripts) and the
> program to test (Boost Build). I'd categorize existing Boost Jam
> tests and testing framework as 'low level' as they do not have an
> external runner but I really do not know what more could be done for
> Boost Build tests.
Well. That's sufficient or maybe the only way for testing the internal
magic like target.jam or alias.jam.
But I've got to test if BBv2 sets up includes, defines and library
paths correctly and is able to compile, link and execute a sample
against a complex beast like Qt4 with alls its caveats.
And given the fact that you can configure qt4.jam to have different
locations for all of the above, it may be quite hard for a "end-user"
to debug this...
> Obviously more testing & utility functions could be added but
> nothing in the test framework design prevents this. Also, possibly a
> bridge could be made between Boost Build towards its testing system
> so that those tests could be run from a Boost Build script and so get
> integrated into regular Boost library tests but again - I do not
> think anything in the test system design prevents this.
>
> > But I'd rather do the testing on "end-user" level.
>
> Again... not sure what 'end-user level' means here.
Someone who just uses Boost.Build. My Jamfile contain something along:
[ run qtcore.cpp /qt//QtCore ]
so I've got both a test-case for finding out whether compiling, linking
and execution against QtCore works as well as an example on how to
write sich a Jamfile. Could even be linked to from the docs.
And using QtTest is non-trivial, because no-one would think of
# ToDo: better support for "automoc" aka '#include "qttest.moc"'
[ run qttest.cpp [ cast _ moccable-cpp : qttest.cpp ] /qt//QtTest ]
in order to run the moc on qttest.cpp (which is the way Qt's automagic
test registration works.
Okay, I should try and start documenting this :-))
Will try this after I got the refactored qt4.jam into trunk (after the
final release merges)
Yours,
Jürgen
-- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold_at_[hidden] ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk