Hello there this is your hometown Meson build system user here just happen to have a
question related to unit testing in D.

So is there a way to run the unit-test in the test main as a costume test runner in
"test/test.d", and run the executable program in "src/main.d", with this resulting in two
executable binaries one for test and one for the program?

I was considering using Unity test framework so I would know that if I was running the test runner that it was definitely the custom test runner returning the value of all test cases ran and not a mistake of running the main executable program.  But I am not sure if that would insulate the D programming community by not using the provided unit testing functionality in D.

I am mostly trying to make a version based on an existing C template but with D language
syntax using whatever tools D provides along side Meson build system.  I would give you
the link(s) but I haven't figured out how to add links here on the D forum, and I just
registered.

Thanks...

Am 18.05.19 um 08:20 schrieb Mike Brockus:
> Hello there this is your hometown Meson build system user here just
> happen to have a
> question related to unit testing in D.
> 
> So is there a way to run the unit-test in the test main as a costume
> test runner in
> "test/test.d", and run the executable program in "src/main.d", with this
> resulting in two
> executable binaries one for test and one for the program?
> 
> I was considering using Unity test framework so I would know that if I was running the test runner that it was definitely the custom test runner returning the value of all test cases ran and not a mistake of running the main executable program.  But I am not sure if that would insulate the D programming community by not using the provided unit testing functionality in D.
> 
> I am mostly trying to make a version based on an existing C template but
> with D language
> syntax using whatever tools D provides along side Meson build system.  I
> would give you
> the link(s) but I haven't figured out how to add links here on the D
> forum, and I just
> registered.
> 
> Thanks...

Hey there,

I already tried to answer your questions on reddit.

You can post links here by simply pasting the URL (the link will not be highlighted in the editor, but it will be when it is posted).

Regarding your problem: Could you please describe what you are actually trying to do? Are you trying to use D in an exisiting Meson project (as an addition to the existing code)? Why are you trying to use the Unity test framework (I only had a quick look at it, but from what I saw it uses a lot of preprocessor macros which will make it difficult to get it wotk work properly with D). Why not use the built-in unittests or one of the many already existing unit testing frameworks for D ([1], [2], [3], [4], [5])?

[1] https://code.dlang.org/packages/unit-threaded
[2] https://code.dlang.org/packages/dunit
[3] https://code.dlang.org/packages/d-unit
[4] https://code.dlang.org/packages/fluent-asserts
[5] https://code.dlang.org/packages/trial

On Sunday, 19 May 2019 at 07:46:11 UTC, Johannes Loher wrote:
> Am 18.05.19 um 08:20 schrieb Mike Brockus:
>> Hello there this is your hometown Meson build system user here just
>> happen to have a
>> question related to unit testing in D.
>> 
>> So is there a way to run the unit-test in the test main as a costume
>> test runner in
>> "test/test.d", and run the executable program in "src/main.d", with this
>> resulting in two
>> executable binaries one for test and one for the program?
>> 
>> I was considering using Unity test framework so I would know that if I was running the test runner that it was definitely the custom test runner returning the value of all test cases ran and not a mistake of running the main executable program.  But I am not sure if that would insulate the D programming community by not using the provided unit testing functionality in D.
>> 
>> I am mostly trying to make a version based on an existing C template but
>> with D language
>> syntax using whatever tools D provides along side Meson build system.  I
>> would give you
>> the link(s) but I haven't figured out how to add links here on the D
>> forum, and I just
>> registered.
>> 
>> Thanks...
>
> Hey there,
>
> I already tried to answer your questions on reddit.
>
> You can post links here by simply pasting the URL (the link will not be highlighted in the editor, but it will be when it is posted).
>
> Regarding your problem: Could you please describe what you are actually trying to do? Are you trying to use D in an exisiting Meson project (as an addition to the existing code)? Why are you trying to use the Unity test framework (I only had a quick look at it, but from what I saw it uses a lot of preprocessor macros which will make it difficult to get it wotk work properly with D). Why not use the built-in unittests or one of the many already existing unit testing frameworks for D ([1], [2], [3], [4], [5])?
>
> [1] https://code.dlang.org/packages/unit-threaded
> [2] https://code.dlang.org/packages/dunit
> [3] https://code.dlang.org/packages/d-unit
> [4] https://code.dlang.org/packages/fluent-asserts
> [5] https://code.dlang.org/packages/trial

I am trying to do two things one being able to turn a pure C project into a pure D project without destroying the existing file structure.
The project (https://github.com/squidfarts/c-project.git)

The other is to make a new Arduino UNO board project that leverages existing C and C++ code so I can spend small amounts of time writing new D code as I update all of my Arduino applications.

I would like to use the Unity test framework for that Arduino UNO based project that uses D, C, C++ and both Meson build system and Conan package manager.  The part with C and C++ are just for linking with the Arduino libraries, including exiting classes while I write new D code to replace the existing C and C++ code where ever it makes since.  Conan is used to get both the Unity and CMock from GitHub.

For the pure D project I would like to use whatever D provides me.  Since you provided this list I would start with unit-threaded and see if it can help with this main function problem.

On Sunday, 19 May 2019 at 16:47:39 UTC, Mike Brockus wrote:
> On Sunday, 19 May 2019 at 07:46:11 UTC, Johannes Loher wrote:
>> Am 18.05.19 um 08:20 schrieb Mike Brockus:
>>> [...]
>>
>> Hey there,
>>
>> I already tried to answer your questions on reddit.
>>
>> You can post links here by simply pasting the URL (the link will not be highlighted in the editor, but it will be when it is posted).
>>
>> Regarding your problem: Could you please describe what you are actually trying to do? Are you trying to use D in an exisiting Meson project (as an addition to the existing code)? Why are you trying to use the Unity test framework (I only had a quick look at it, but from what I saw it uses a lot of preprocessor macros which will make it difficult to get it wotk work properly with D). Why not use the built-in unittests or one of the many already existing unit testing frameworks for D ([1], [2], [3], [4], [5])?
>>
>> [1] https://code.dlang.org/packages/unit-threaded
>> [2] https://code.dlang.org/packages/dunit
>> [3] https://code.dlang.org/packages/d-unit
>> [4] https://code.dlang.org/packages/fluent-asserts
>> [5] https://code.dlang.org/packages/trial
>
> I am trying to do two things one being able to turn a pure C project into a pure D project without destroying the existing file structure.
> The project (https://github.com/squidfarts/c-project.git)
>
> The other is to make a new Arduino UNO board project that leverages existing C and C++ code so I can spend small amounts of time writing new D code as I update all of my Arduino applications.
>
> I would like to use the Unity test framework for that Arduino UNO based project that uses D, C, C++ and both Meson build system and Conan package manager.  The part with C and C++ are just for linking with the Arduino libraries, including exiting classes while I write new D code to replace the existing C and C++ code where ever it makes since.  Conan is used to get both the Unity and CMock from GitHub.
>
> For the pure D project I would like to use whatever D provides me.  Since you provided this list I would start with unit-threaded and see if it can help with this main function problem.

Hey again, does my answer from reddit not solve your first problem (keeping the existing file structure)? As mentioned, using Unity for the tests does not really make sense with D, though it might be possible to use it with dpp ([1]).

Regarding your second problem: The Arduino UNO is based on the ATmega328P, which is an AVR chip. There is currently no D compiler available, that targets AVR, so you won‘t be able to use D for programming your Arduino UNO for now. There have been discussions about this ([2], [3]), but for now it is simply not possible.

[1] https://github.com/atilaneves/dpp
[2] https://forum.dlang.org/thread/1328258826.2142.4.camel@ububox?page=1
[3] https://forum.dlang.org/thread/zvderukicijcuxgqgwzk@forum.dlang.org

On Tuesday, 21 May 2019 at 03:07:20 UTC, Johannes Loher wrote:
> On Sunday, 19 May 2019 at 16:47:39 UTC, Mike Brockus wrote:
>> On Sunday, 19 May 2019 at 07:46:11 UTC, Johannes Loher wrote:
>>> Am 18.05.19 um 08:20 schrieb Mike Brockus:
>>>> [...]
>>>
>>> Hey there,
>>>
>>> I already tried to answer your questions on reddit.
>>>
>>> You can post links here by simply pasting the URL (the link will not be highlighted in the editor, but it will be when it is posted).
>>>
>>> Regarding your problem: Could you please describe what you are actually trying to do? Are you trying to use D in an exisiting Meson project (as an addition to the existing code)? Why are you trying to use the Unity test framework (I only had a quick look at it, but from what I saw it uses a lot of preprocessor macros which will make it difficult to get it wotk work properly with D). Why not use the built-in unittests or one of the many already existing unit testing frameworks for D ([1], [2], [3], [4], [5])?
>>>
>>> [1] https://code.dlang.org/packages/unit-threaded
>>> [2] https://code.dlang.org/packages/dunit
>>> [3] https://code.dlang.org/packages/d-unit
>>> [4] https://code.dlang.org/packages/fluent-asserts
>>> [5] https://code.dlang.org/packages/trial
>>
>> I am trying to do two things one being able to turn a pure C project into a pure D project without destroying the existing file structure.
>> The project (https://github.com/squidfarts/c-project.git)
>>
>> The other is to make a new Arduino UNO board project that leverages existing C and C++ code so I can spend small amounts of time writing new D code as I update all of my Arduino applications.
>>
>> I would like to use the Unity test framework for that Arduino UNO based project that uses D, C, C++ and both Meson build system and Conan package manager.  The part with C and C++ are just for linking with the Arduino libraries, including exiting classes while I write new D code to replace the existing C and C++ code where ever it makes since.  Conan is used to get both the Unity and CMock from GitHub.
>>
>> For the pure D project I would like to use whatever D provides me.  Since you provided this list I would start with unit-threaded and see if it can help with this main function problem.
>
> Hey again, does my answer from reddit not solve your first problem (keeping the existing file structure)? As mentioned, using Unity for the tests does not really make sense with D, though it might be possible to use it with dpp ([1]).
>
> Regarding your second problem: The Arduino UNO is based on the ATmega328P, which is an AVR chip. There is currently no D compiler available, that targets AVR, so you won‘t be able to use D for programming your Arduino UNO for now. There have been discussions about this ([2], [3]), but for now it is simply not possible.
>
> [1] https://github.com/atilaneves/dpp
> [2] https://forum.dlang.org/thread/1328258826.2142.4.camel@ububox?page=1
> [3] https://forum.dlang.org/thread/zvderukicijcuxgqgwzk@forum.dlang.org

The solution from Reddit solves the problem for 'dub' but as part of my project C to D I wanted to use Meson and run test with whatever is available, coming next week I will try to incorporate 'unit-threaded' and if it works then I can tell Meson to include it as my decency and to use 'dub' to get it for me so I can focus on writing test for my code.  I am currently working on becoming an Android app developer leaning Kotlin and on the weekends it's D.

As for Arduino I was thinking more in the ways of using D to interface with existing C functionality in the Arduino, for this to work I think I just need to tell Meson to make this a C, C++, D project.  Something like this:

# Root meson.build

project('uno_proj', 'c', 'cpp', 'd')# this would work...

subdir('src')



# src/main.d
extern (C) void setup(); // This should call the defections for the most important
extern (C) void loop();  // functions in any Arduino program.


void setup()
{
    // some code here.
}// end of function setup

void loop()
{
    // Whatever the program needs to do.
}// end of function loop



In the actual project the meson.build in the 'src' directory is where I manage generating the other required files also, this was just meant to be like pseudocode example to give some idea as to what I meant.

However it is good to know that there is currently no compiler for D on a AVR chip.

On Tue, 2019-05-21 at 05:21 +0000, Mike Brockus via Digitalmars-d-learn wrote:
> 
[…]
> The solution from Reddit solves the problem for 'dub' but as part of my project C to D I wanted to use Meson and run test with whatever is available, coming next week I will try to incorporate 'unit-threaded' and if it works then I can tell Meson to include it as my decency and to use 'dub' to get it for me so I can focus on writing test for my code.  I am currently working on becoming an Android app developer leaning Kotlin and on the weekends it's D.

I use unit-threaded for my D code tests. Atila was kind enough to allow me to add a Meson build to unit-threaded. I therefore build and install a shared library of unit-threaded so as to avoid use of Dub in the Meson build of my D projects.

> […]
> 
> However it is good to know that there is currently no compiler for D on a AVR chip.

I thought GCC had an AVR backend so that GDC provides D on AVR.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tuesday, 21 May 2019 at 10:59:40 UTC, Russel Winder wrote:
> On Tue, 2019-05-21 at 05:21 +0000, Mike Brockus via Digitalmars-d-learn wrote:
>> 
> […]
>> The solution from Reddit solves the problem for 'dub' but as part of my project C to D I wanted to use Meson and run test with whatever is available, coming next week I will try to incorporate 'unit-threaded' and if it works then I can tell Meson to include it as my decency and to use 'dub' to get it for me so I can focus on writing test for my code.  I am currently working on becoming an Android app developer leaning Kotlin and on the weekends it's D.
>
> I use unit-threaded for my D code tests. Atila was kind enough to allow me to add a Meson build to unit-threaded. I therefore build and install a shared library of unit-threaded so as to avoid use of Dub in the Meson build of my D projects.
>
>> […]
>> 
>> However it is good to know that there is currently no compiler for D on a AVR chip.
>
> I thought GCC had an AVR backend so that GDC provides D on AVR.

That is cool that Atila was kind enough to accept the meson.build file.  But how do I use the written meson.build that is apparently in the subdirectory directory "build"?  Just asking because normally I see a meson.build in the root of the project.

On Thu, 2019-05-23 at 04:21 +0000, Mike Brockus via Digitalmars-d-learn wrote:
> […]
> 
> That is cool that Atila was kind enough to accept the meson.build file.  But how do I use the written meson.build that is apparently in the subdirectory directory "build"?  Just asking because normally I see a meson.build in the root of the project.

Having the meson.build in the project root directory is the norm, and that was where I put it originally. However, Atila chose to leave only the Dub build in the root directory and place all other build-related files in the build directory. This is not a problem since Meson is entirely happy with that structure.

I have my clone of unit-threaded in
~/Repositories/Git/Fork/Unit_Threaded and
I build in ~/BuildArea/Unit_Threaded. My meson command in the build
directory is:

meson --prefix=$HOME/Built ~/Repositories/Git/Fork/Unit_Threaded/built

and this works fine. I then build and install using Ninja. To date it all works for me. If you try this and something goes wrong put an issue on the unit-threaded GitHub project area and email me in case I don't get a notification from the issue system.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 23 May 2019 at 06:14:11 UTC, Russel Winder wrote:
> On Thu, 2019-05-23 at 04:21 +0000, Mike Brockus via Digitalmars-d-learn wrote:
>> […]
>> 
>> That is cool that Atila was kind enough to accept the meson.build file.  But how do I use the written meson.build that is apparently in the subdirectory directory "build"?  Just asking because normally I see a meson.build in the root of the project.
>
> Having the meson.build in the project root directory is the norm, and that was where I put it originally. However, Atila chose to leave only the Dub build in the root directory and place all other build-related files in the build directory. This is not a problem since Meson is entirely happy with that structure.
>
> I have my clone of unit-threaded in
> ~/Repositories/Git/Fork/Unit_Threaded and
> I build in ~/BuildArea/Unit_Threaded. My meson command in the build
> directory is:
>
> meson --prefix=$HOME/Built ~/Repositories/Git/Fork/Unit_Threaded/built
>
> and this works fine. I then build and install using Ninja. To date it all works for me. If you try this and something goes wrong put an issue on the unit-threaded GitHub project area and email me in case I don't get a notification from the issue system.

I tried that custom command voodoo then I tried to use 'dub' as a method for hunting down dependencies.  Basically got something like this.

'''
    Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on May  4 2019)
    Dependency unit-threaded found: NO

    meson.build:71:0: ERROR: Dependency "unit-threaded" not found
'''

On Mon, 2019-05-27 at 16:13 +0000, Mike Brockus via Digitalmars-d-learn wrote:
> […]
> 
> I tried that custom command voodoo then I tried to use 'dub' as a method for hunting down dependencies.  Basically got something like this.

Apologies but I am not sure what you have tried. Installing unit- threaded as a shared library is so as to build a D project without dub at all. What I didn't say in the previous email is that if you are installing libraries not to the standard place you have to set some environment variables. In my case, consistent with the build instructions I gave for my case:

PKG_CONFIG_PATH=.:/home/users/russel/Built/share/pkgconfig:/home/users/russel/Built/lib/pkgconfig LD_LIBRARY_PATH=.:/home/users/russel/Built/lib

Having . in the paths is not something everyone does though.

> '''
>      Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on
> May  4 2019)
>      Dependency unit-threaded found: NO
> 
>      meson.build:71:0: ERROR: Dependency "unit-threaded" not found
> '''

This seems like you are using Dub from within the Meson/Ninja build, this is not something I do. I know you can use Dub from Meson to deal with dependencies, but this is not something I do. I build all the dependencies and then build the application without Dub.

If using Dub from Meson to handle dependencies becomes the de facto standard I'll give it a whirl.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk