Whether or not they are enabled by default is a different issue. I
don't care if they are enabled by default. I only care that I can
disable them. Currently I can't disable them from being built. This
means that I cannot avoid the extra dependencies the tests bring in.
To work around this, I have to patch scons like this:
diff --git a/resource/unittests/SConscript b/resource/unittests/SConscript
index cdb9ca7..ac0d9e4 100644
--- a/resource/unittests/SConscript
+++ b/resource/unittests/SConscript
@@ -65,7 +65,8 @@ if env.get('LOGGING'):
######################################################################
# Source files and Targets
######################################################################
-unittests = unittests_env.Program('unittests', ['ConstructResourceTest.cpp',
+if env.get('TEST') == '1':
+ unittests = unittests_env.Program('unittests',
['ConstructResourceTest.cpp',
'OCPlatformTest.cpp',
'OCRepresentationTest.cpp',
'OCResourceTest.cpp',
@@ -73,10 +74,10 @@ unittests = unittests_env.Program('unittests',
['ConstructResourceTest.cpp',
'OCResourceResponseTest.cpp',
'OCHeaderOptionTest.cpp'])
-Alias("unittests", [unittests])
+ Alias("unittests", [unittests])
+
+ env.AppendTarget('unittests')
-env.AppendTarget('unittests')
-if env.get('TEST') == '1':
target_os = env.get('TARGET_OS')
if target_os == 'linux':
out_dir = env.get('BUILD_DIR')
On Thu, Jun 11, 2015 at 10:17 PM, Jon A. Cruz <jonc at osg.samsung.com> wrote:
> On 06/11/2015 01:44 PM, Rees, Kevron wrote:
>> On Thu, Jun 11, 2015 at 9:21 AM, Keane, Erich <erich.keane at intel.com>
>> wrote:
>>> On Thu, 2015-06-11 at 14:17 +0000, Lankswert, Patrick wrote:
> [SNIP]
>>>>
>>>> Regarding unit tests; is 'TEST=0' currently a build option?
>>> It IS an option, but it means "Don't Run Unit Tests (default)", not
>>> "Don't build Unit Tests".
>>>
>>
>> Oh. Okay. I figured it was both because why would you build
>> something you aren't going to run? :P
>>
>
> Oh, that's a very simple point to answer.
>
> If a default build did not also build the unit tests, then they would
> only ever be built when explicitly asked for. Since we're living in an
> imperfect world, experience has shown that a large number of developers
> will not explicitly enable unit testing. Then final (and all too common)
> result is that in very short order unit tests will become out of date
> and their code broken.
>
> Keeping unit tests as part of the main build ensures that they don't
> become significantly stale. Enabling their running by default can help
> even more, but normally takes educating contributors on what makes good
> build-time tests vs. longer ones.
>
> So by building things that aren't always run you can do things like
> ensure API changes don't break all the handy tests you started with.
>
> --
> Jon A. Cruz - Senior Open Source Developer
> Samsung Open Source Group
> jonc at osg.samsung.com
