What's best practice to incorporate Boost.Test in own project?
Hi, I'm going to add Unit Tests to one of projects. It's quite big project, so there will be many tests suits and cases. The project build system is based on automake for Unix and nmake for Windows. I wonder what is the best practice to include Boost.Test frameworks to my own project? Currently I consider only Unit Test Framework. I see following possibilities: 1. Boost libraries are installed from official release (precompiled or compiled by user) Makefiles for my project try to detect if Boost exists and link to Unit Test Framework librar. Here Boost has to be listed in compilation requirements of my project. 2. Boost.Test libraries in binary form are included to my project tree and shipped together. So there is no requirement to have complete Boost installed, because test can link to UTF library already present 3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user. I'd like to know your comments about which solution is best and what are possible traps hidding. Regarding the 1 solution I think there may be possible problem with using incorrect Boost.Test version. The second one involves additional work for overall projct maintenance. May be there are more possibilities I've not listed above, so please share your ideas. Thanks in advance for your comments. Best regards -- Mateusz Łoskot http://mateusz.loskot.net
Mateusz Łoskot wrote:
Hi,
I'm going to add Unit Tests to one of projects. It's quite big project, so there will be many tests suits and cases. The project build system is based on automake for Unix and nmake for Windows. I wonder what is the best practice to include Boost.Test frameworks to my own project?
Currently I consider only Unit Test Framework.
I see following possibilities:
1. Boost libraries are installed from official release (precompiled or compiled by user) Makefiles for my project try to detect if Boost exists and link to Unit Test Framework librar. Here Boost has to be listed in compilation requirements of my project.
2. Boost.Test libraries in binary form are included to my project tree and shipped together. So there is no requirement to have complete Boost installed, because test can link to UTF library already present
3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user.
I'd like to know your comments about which solution is best and what are possible traps hidding. Regarding the 1 solution I think there may be possible problem with using incorrect Boost.Test version. The second one involves additional work for overall projct maintenance.
May be there are more possibilities I've not listed above, so please share your ideas.
Thanks in advance for your comments. Best regards
Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include <boost/test/included/unit_test_framework.hpp> to your project and compile everything using your build system, isn't it? --dima
Dmitry wrote:
Mateusz Łoskot wrote:
3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user.
Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include <boost/test/included/unit_test_framework.hpp> to your project and compile everything using your build system, isn't it?
Hi Dmitry, But what about building Unit Test Framework library? How should I provide building it? Using bjam (bjam would be requirement) or own home-made makefiles for UTF? Cheers -- Mateusz Łoskot http://mateusz.loskot.net
Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include <boost/test/included/unit_test_framework.hpp> to your project and compile everything using your build system, isn't it? --dima
I wouldn't recommend using this option on a permanent basis. You don't know what kind of hardware users are using and how slow above solution would be. Also this solution still leave you with boost dependency (particular version of it). So there is no much with in comparison with rebuilt library. Gennadiy
Gennadiy Rozental wrote:
Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include <boost/test/included/unit_test_framework.hpp> to your project and compile everything using your build system, isn't it? --dima
I wouldn't recommend using this option on a permanent basis. You don't know what kind of hardware users are using and how slow above solution would be. Also this solution still leave you with boost dependency (particular version of it). So there is no much with in comparison with rebuilt library.
That's clear for me. Thank you Cheers -- Mateusz Łoskot http://mateusz.loskot.net
Mateusz Łoskot wrote:
Gennadiy Rozental wrote:
Hello Mateusz, One obsevation concerning 3th approach for using boost.test framework. You just can include #include <boost/test/included/unit_test_framework.hpp> to your project and compile everything using your build system, isn't it? --dima
I wouldn't recommend using this option on a permanent basis. You don't know what kind of hardware users are using and how slow above solution would be. Also this solution still leave you with boost dependency (particular version of it). So there is no much with in comparison with rebuilt library.
That's clear for me. Thank you
Cheers Ups, sorry for bad avices and misunderstanding(( Shame on my gray head, --dima
"Mateusz Loskot" <mateusz@loskot.net> wrote in message news:duf9bl$72t$1@sea.gmane.org...
Hi,
I'm going to add Unit Tests to one of projects. It's quite big project, so there will be many tests suits and cases. The project build system is based on automake for Unix and nmake for Windows. I wonder what is the best practice to include Boost.Test frameworks to my own project?
Currently I consider only Unit Test Framework.
I see following possibilities:
1. Boost libraries are installed from official release (precompiled or compiled by user) Makefiles for my project try to detect if Boost exists and link to Unit Test Framework librar. Here Boost has to be listed in compilation requirements of my project.
This option is more or less safe. Since: 1. Boost is installed in many places now 2. Your own code is quite possibly will have to use boost itself. Don't forget though that you will depend on some particular version of boost. Not just any available.
2. Boost.Test libraries in binary form are included to my project tree and shipped together. So there is no requirement to have complete Boost installed, because test can link to UTF library already present
This option is probable safest. Becuse you doesn't require boost dependencies and doesn't require particular version of boost installed. On the other hand it will enlange the size of you deliverables.
3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user.
UTF building doen't require that much effort. User could use any make system without probles. There is no additional options required Look on compilation intrsuction in cvs. bjam really is not that complicated either. Just something many not familiar with.
I'd like to know your comments about which solution is best and what are possible traps hidding. Regarding the 1 solution I think there may be possible problem with using incorrect Boost.Test version. The second one involves additional work for overall projct maintenance.
You right on both counts. I would supply prebuilt UTF binaries as a separate optional. delivarable. Happy owners of proper boost version could use their UTF (build one first one way or another). The rest could download one you supply. Regards, Gennadiy
Hi Gennadiy, Gennadiy Rozental wrote:
"Mateusz Loskot" <mateusz@loskot.net> wrote:
I see following possibilities:
1. Boost libraries are installed from official release (precompiled or compiled by user) Makefiles for my project try to detect if Boost exists and link to Unit Test Framework librar. Here Boost has to be listed in compilation requirements of my project.
This option is more or less safe. Since:
1. Boost is installed in many places now 2. Your own code is quite possibly will have to use boost itself.
Don't forget though that you will depend on some particular version of boost. Not just any available.
Yes. I think this is the only disadvantage I can see in this solution.
2. Boost.Test libraries in binary form are included to my project tree and shipped together. So there is no requirement to have complete Boost installed, because test can link to UTF library already present
This option is probable safest. Becuse you doesn't require boost dependencies and doesn't require particular version of boost installed. On the other hand it will enlange the size of you deliverables.
Yes, you're right.
3. Include Boost.Test source code and allow user of my project to build UTF library on his own. Here I expect some problems with bjam/makefiles incompatibility. So, bjam would be required on user's platform. Simply, this solution seems to be quite confusing for user.
UTF building doen't require that much effort.
Yes, I think so. I learned it recently, so I see there should not be a problem to write makefile to build UTF lib, as well as create VC++ project file (what I've already done easily).
User could use any make system without probles. There is no additional options required Look on compilation intrsuction in cvs.
That's right.
bjam really is not that complicated either. Just something many not familiar with.
Huh! I've heared something different :-) But I'm not going to discuss bjam here.
I'd like to know your comments about which solution is best and what are possible traps hidding. Regarding the 1 solution I think there may be possible problem with using incorrect Boost.Test version. The second one involves additional work for overall projct maintenance.
You right on both counts. I would supply prebuilt UTF binaries as a separate optional. delivarable. Happy owners of proper boost version could use their UTF (build one first one way or another). The rest could download one you supply.
You're recommendation sounds very good. I think I'll stick to it. Thank you -- Mateusz Łoskot http://mateusz.loskot.net
participants (3)
-
Dmitry -
Gennadiy Rozental -
Mateusz Łoskot