On Thursday, 20 September 2012 at 18:31:38 UTC, Jacob Carlborg wrote:
> On 2012-09-20 13:14, Jonathan M Davis wrote:
>> On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
>>> But it should be possible.
>>
>> I'm not arguing that it shouldn't be possible. I'm just pointing out that it
>> wouldn't really be useful. You have to build at least two versions of your
>> library anyway (one with -unittest and one without), so being forced to build
>> your library as a binary for unit tests really isn't a big deal IMHO. But I
>> have no problem with it working to link in a library built with -unittest and
>> have its unit tests run.
>
> You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version.

I have the same issue.

My point is related to IDE usage, I need provide a library for my samples projects and for users. I don't want have to create 2 projects of my "library" one with a main and one without, because in this case each time I add or remove a file I need do this manipulation for both projects.

I try the "-main" option of dmd that need "add default main() (e.g. for unittesting)", reading it like that I though it was exactly to be able to put a library project as executable.

PS : I am using VisualD and MonoD.

I also searched if it is possible to create one d file that imports all my library sources just like we do with a #include "build-all.c".

Sadly we can't create a Visual project that contains only D sources without any building steps, instead we could put this project of files references as dependency. All samples projects would be build with the library code.

On Friday, 8 November 2013 at 20:29:19 UTC, Flamaros wrote:
> On Thursday, 20 September 2012 at 18:31:38 UTC, Jacob Carlborg wrote:
>> On 2012-09-20 13:14, Jonathan M Davis wrote:
>>> On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote:
>>>> But it should be possible.
>>>
>>> I'm not arguing that it shouldn't be possible. I'm just pointing out that it
>>> wouldn't really be useful. You have to build at least two versions of your
>>> library anyway (one with -unittest and one without), so being forced to build
>>> your library as a binary for unit tests really isn't a big deal IMHO. But I
>>> have no problem with it working to link in a library built with -unittest and
>>> have its unit tests run.
>>
>> You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version.
>
> I have the same issue.
>
> My point is related to IDE usage, I need provide a library for my samples projects and for users. I don't want have to create 2 projects of my "library" one with a main and one without, because in this case each time I add or remove a file I need do this manipulation for both projects.
>
> I try the "-main" option of dmd that need "add default main() (e.g. for unittesting)", reading it like that I though it was exactly to be able to put a library project as executable.
>
> PS : I am using VisualD and MonoD.
>
> I also searched if it is possible to create one d file that imports all my library sources just like we do with a #include "build-all.c".
>
> Sadly we can't create a Visual project that contains only D sources without any building steps, instead we could put this project of files references as dependency. All samples projects would be build with the library code.

I find a way by adding new build configuration that allow my to build an executable binary and run unittests of my "library". This solution works well with VisualD, but it stuck with MonoD, because new configuration can't be selected to run it.