Hi D

I've started a D layer for one of my C libraries that's adds some new functionality and a bit of an interface upgrade.  In turn I'm using this combined code-base as a dependency for D "scripts".  Since my software is used by a few outside groups in my field, it seems I should get used to packaging D modules, even if those packages never make it to the central dub repo.

Given that source code for the combined library is some D but mostly C, would you recommend that I:

  1) Keep the D sources and C sources in separate projects?
  2) Use meson to create a combined package?
  3) Use dub to create a combined package?
  4) Some other option?

The D code is useless without it's C core, so a dub package that just includes the D parts would be disappointing.  The library's not huge, only about 25K lines, but I don't think I have time for a straight conversion of the whole thing to D at this point.

Thanks for your opinions on the matter,

Meson doesn't track dependencies properly for d, so your dirty builds will be wrong if you go that route.

You might consider keeping the c and d code in the same repository, but with separate build systems; using dub to build the d code and and whatever tool you prefer for c.  Or try reggae.

On Thursday, 18 March 2021 at 02:28:56 UTC, Chris Piker wrote:
> Hi D
>
> I've started a D layer for one of my C libraries that's adds some new functionality and a bit of an interface upgrade.  In turn I'm using this combined code-base as a dependency for D "scripts".  Since my software is used by a few outside groups in my field, it seems I should get used to packaging D modules, even if those packages never make it to the central dub repo.
>
> Given that source code for the combined library is some D but mostly C, would you recommend that I:
>
>   1) Keep the D sources and C sources in separate projects?
>   2) Use meson to create a combined package?
>   3) Use dub to create a combined package?
>   4) Some other option?
>
> The D code is useless without it's C core, so a dub package that just includes the D parts would be disappointing.  The library's not huge, only about 25K lines, but I don't think I have time for a straight conversion of the whole thing to D at this point.
>
> Thanks for your opinions on the matter,

The D support from meson is not perfect, but for your use case I'd go for it, esp. if you have do not have many dependencies on dub packages.

One problem with meson is that it goes the separate compilation route by default. I recommend just to -I your dependencies and build with -i, to avoid the hit in your compile times.

On Thursday, 18 March 2021 at 06:02:03 UTC, Elronnd wrote:
> Meson doesn't track dependencies properly for d, so your dirty builds will be wrong if you go that route.
>
> You might consider keeping the c and d code in the same repository, but with separate build systems; using dub to build the d code and and whatever tool you prefer for c.  Or try reggae.

Hi Elronnd

You might be right.  Since Visual D is highly spoken of on these forums I decided to give it a go.  I don't usually write software on Windows, and I have to say that once I stepped outside the D ecosystem the experience was not good.  There's no standard locations for
anything.  Meson worked well on Linux, but I can't figure out how to get it to find vcpkg dependencies on Windows.  Outside Visual D, the one thing that worked great on windows was:

   dub

I know everyone knocks the idea of downloading your dependencies off the web, but when starting from scratch you have to get them from somewhere and dub comes to the rescue,
and "add-path" is there for local packages.

Has there ever been talk of adding C source code support to dub, or is that a forbidden topic?  I know if dub supported C, all my C libs and all my necessary dependencies (openssl, expat, etc.) would have dub.json files before the weekend was over.

On 3/19/21 4:04 AM, Chris Piker wrote:
> 
> Has there ever been talk of adding C source code support to dub, or is that a forbidden topic?  I know if dub supported C, all my C libs and all my necessary dependencies (openssl, expat, etc.) would have dub.json files before the weekend was over.
> 

Chris: for one of my (D) libraries that also links in an .o file that's built from C source, I have a makefile for the C and call `make` during the dub build process.

It is not incredibly sophisticated, but works well for us. Here is the dubfile with `preBuildCommands`:

https://github.com/blachlylab/intervaltree/blob/master/dub.json

Kind regards

On Saturday, 20 March 2021 at 18:33:20 UTC, James Blachly wrote:
> Chris: for one of my (D) libraries that also links in an .o file that's built from C source, I have a makefile for the C and call `make` during the dub build process.
>
> It is not incredibly sophisticated, but works well for us. Here is the dubfile with `preBuildCommands`:
>
> https://github.com/blachlylab/intervaltree/blob/master/dub.json

James: Nice concrete example, thanks!  My code is cross platform, so I'll try to adapt what you have to a version that invokes nmake.exe if run in a visual studio environment.

Take Care,