Need help adding nar-test to pom

[Ian]

TL;DR: Have a working NAR project that outputs shared object - need to compile/run native code unit test after SO is built. Need to use different <c> and <linker> options for 'main' SO build process and unit test build process.



I'm looking for some help using nar:nar-test in my project.

I have a nar project that builds a native SO. I want to specify a native code test that links in the project's SO (along with other libraries/includes). I then want to run that test and fail the build if the exit code is non-zero. I have seen examples such as:

https://github.com/maven-nar/nar-maven-plugin/blob/2b6dc501f11475baa9649f47ee5ce1a93e90b497/src/it/it0016-layout/it0016-lib-layout20/pom.xml

However, I require the ability to pass args to gcc and the linker, like what is done with <c> and <linker> blocks in the 'main build'

1) Is nar-test the right tree to be barking up? It seems like it integrates into the maven test life-cycle.

2) If so, where should this live in the pom? My intuition says it should live inside the <configuration> block for nar-maven-plugin. Adding a <nar-test> block seems to do nothing however.

I feel like I'm missing something obvious here.. can anyone point me in the right direction? Examples would be fantastic.

Thanks much,
-Ian

[Curtis Rueden]

Hi Ian,

> TL;DR:  Have a working NAR project that outputs shared object - need

> to compile/run native code unit test after SO is built.  Need to use

> different <c> and <linker> options for 'main' SO build process and

> unit test build process.

Unfortunately, I am far from an expert on the NAR code. But it sounds like you could accomplish what you want by creating a downstream project to perform the test. Or to keep it part of the same module, you could structure it as an IT, like many of the NAR integration tests (since ITs are effectively separate downstream projects).

But maybe someone else on this list known the right way to use the nar-test goal...

Regards,

Curtis

--
You received this message because you are subscribed to the Google Groups "NAR Maven plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-nar+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Curtis Rueden]

Hi Jef,

Great writeup! Would you care to add it as a wiki page? Then it will be more accessible for others.

Regards,
Curtis

On Sep 4, 2016 8:11 AM, "dugilos" <jef....@gmail.com> wrote:

Hello,

If the case is not yet resolved, here is how I use the tests on nar-maven-plugin.

First, by default, the phase test-compile (goal nar:nar-testCompile) will compile the files in src/test to create one or many executables which will be linked against the library built by the project (if the <libraries> <library> <type> in <configuration> is "static" or "shared").

The compiler and the linker used when building the test executables can have some specific options, but theses options will be added to the options used to build the library !

Here is how to define those options :

<configuration>
    <c>
        <name>gcc</name>
       
        <options>
            ...
        </options>

        <testOptions>
            <!-- testOptions are added to regular options for test compilation -->
            ...
        </testOptions>
    </c>
    <cpp>
        <name>g++</name>
       
        <options>
            ...
        </options>

        <testOptions>
            <!-- testOptions are added to regular options for test compilation -->
            ...
        </testOptions>
    </cpp>
    <linker>
        <name>g++</name>
        <options>
            ...
        </options>

        <testOptions>
            <!-- testOptions are added to regular options for test linkage -->
            ...
        </testOptions>
    </linker>
</configuration>

A consequence of the fact that the test options are added to the regular options, is that if you build a static library, the <linker> <options> must be empty as the ar command doesn't take any "gcc option", but the <linker> <testOptions> must contain all the gcc linker options to build the test executables.

Second, to define the test executables which will be built, you must use the <tests> <test> elements, example :

<configuration>

    <tests>

        <test>
            <name>testOne</name>
            <link>shared</link>
            <run>true</run>
        </test>

        <test>
            <name>testTwo</name>
            <link>shared</link>
            <run>true</run>
            <args>
                <arg>param1</arg>
                <arg>param2</arg>
            </args>
        </test>

    </tests>

</configuration>

The configuration above will build 2 executables, testOne and testTwo, each executable will be built with all the test source files whose names don't correspond to the names of other tests.

If we have 4 files in src/test/c for example, main.c, util.c, testOne.c and testTwo.c, the executable testOne will be built from main.c, util.c and testOne.c (testTwo.c is not retained because it has the same name of another test), and the executable testTwo will be built from main.c, util.c and testTwo.c.
Of course you can have only one source file per test with the name of the test, each executable will then be built only from its source file.

Note : my tests files are always c++ files (src/test/c++/(filenames).cpp), the filtering of test files above works with cpp files names, but I gess it works the same with c files names.

And I set <test> <link> value with "static" or "shared" accordingly to the type of the library I test, I never tried to set the other type to see what happens ...

And third, with the <test> <run> with the value "true", the test executables are run on the phase test (goal nar:nar-test), and if the return value of one of the executions is not 0, the test is failed and the build is failed.

That's all I know, I hope it responds to the demand :)

Jef

[dugilos]

[dugilos]

(Oups I didn't see it was from 2015, I only looked on the month, sorry for the bump !)

Le samedi 22 août 2015 05:59:58 UTC+2, Curtis Rueden a écrit :

[dugilos]

Hi, thanks, yes good idea, I will do some tests to be sure that all is working as stated (I am pretty confident), and I will add a wiki page with some example.

[dugilos]

Hi,

Here is an example for the wiki : https://github.com/dugilos/nar-maven-plugin/wiki/nar-test
(I created it in my repository as a draft).

If you are ok with the content, I will copy it in the plugin wiki.

Regards,
Dugilos / Jef

[Curtis Rueden]

Thanks. At a glance, it looks nice. Sorry I don't have time to review it in detail. But it would be great to add to the main wiki.

--

Curtis Rueden

LOCI software architect - http://loci.wisc.edu/software

ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden

Did you know ImageJ has a forum? http://forum.imagej.net/

To unsubscribe from this group and stop receiving emails from it, send an email to maven-nar+unsubscribe@googlegroups.com.