File	Date	Author	Commit
my_test_program	2009-11-15	Marek Wieckowski	[6d3793] Initial commit
s-p-r	2009-11-15	Marek Wieckowski	[6d3793] Initial commit
INSTALL.txt	2009-11-15	Marek Wieckowski	[f7cf0b] better comments
README.txt	2009-11-15	Marek Wieckowski	[6d3793] Initial commit
testproject-DYNAMIC.pro	2009-11-15	Marek Wieckowski	[6d3793] Initial commit
testproject-STATIC.pro	2009-11-15	Marek Wieckowski	[6d3793] Initial commit

Read Me

Test program which just calls one function from a file from s-p-r, which should write text "SPR works fine".



Two ways of building projects using s-p-r: Pluses and minuses are basically the same as for any static vs. dynamic linking:

=========== 1. dynamic:
* top-level .pro file uses "subdirs" template
* subdir s-p-r builds spr library (lib template with target "spr")
* subdir YOURPROJECT builds your binary (app template);
	- it includes ../s-p-r in INCLUDEPATH
	- it include proper -L (depending on target dir of s-p-r) and "-lspr" to link against the lib
	- it does NOT include the source files from ../s-p-r in SOURCE/HEADERS/FORMS etc.
Pluses:
+ you don't need to build s-p-r; s-p-r is a separate library wich can be upgraded, shared among different projects etc.
	(in fact, once you have a libspr.so + headers, you can build just the project in your-project subdir, that's all)
+ if s-p-r changes internally (new/renamed files etc.) you don't need to modify anything in your project (e.g. no need to add 
	new sources to your .pro file etc.)
Minuses:
- you have to deploy both your binary and the library; library has to be in LD_LIBRARY_PATH (e.g. if LD_LIB_P includes "." and your binary is in the same directory as libspr.so, you may need to "cd" to this directory before running your binary;
- in your project you get access only to the elements exposed by s-p-r.h file; for example you don't have direct access to the icons from s-p-r project etc.

NOTE: you may still need to ship the proper Qt libs (e.g. when deploying for win32 without qt installed), so it may not be a big problem to include s-p-r dll/lib anyway...

=========== 2. static:
* top-level .pro file uses app template and contains ALL sources: the s-p-r sources from s-p-r dir and your-application sources from your-application dir;
	- you still need to include ./s-p-r in INCLUDEPATH
Pluses:
+ produces one binary, not dependent on s-p-r libs (but note: you may still need to include required qt libs if you expect that users might not have them...)
+ if you include not only sources but also resources, you'll get all the icons etc.

Minuses:
- bigger binary;
- fresh build of your application will always mean a fresh build of s-p-r libs (e.g. no way to use one s-p-r libs files for mulitple projects)

=========================
NOTE: if you do have access to s-p-r sources, you can easily add the spr resorce file to your project, having spr linked dynamically, but still have access to all icons etc.