I am curious to know what barriers prevent dub from supporting C source code compilation.

I have seen many wrapper projects mentioned here, but I think all of these leave handling of external fortran/C/C++ source packages to other systems.  This makes sense for large projects such as Qt.  However, for new D programmers, original C sources may slowly disappear over time while continuing to supply key functionality for quite a while and I presume that getting new programmers is a central goal of the community.

Since dub already works with compilers other than dmd, how much work would it take to make it work with other llvm/gcc supported languages such as fortran/c/c++ ?

Are there fundamental non-technical reasons that support for selected external languages in dub is a bad idea?

Maybe these are naive questions.

I found dub to be especially handy in the wild-west environment of Windows programming and would like to rely on it a bit more.

Kind Regards,

I think it just isn't dub's responsibility to build C code and it adds a
lot of complexity that is difficult to maintain. dub is more of a package
manager with some build system capabilities than a build system. If you look
at how many C/C++ build systems we have, autotools, cmake, meson, you
can see that it isn't a trivial task to get it right. And dub has even
problems with its main task, package management, so there where some
attempts to rewrite it from scratch.

In my opinion it would be better to add D support to existing build systems. Meson supported D, there were cmake intergration for D.

On Sat Mar 20, 2021 at 12:11 AM CET, Chris Piker via Digitalmars-d wrote:
> I am curious to know what barriers prevent dub from supporting C source code compilation.
>
> I have seen many wrapper projects mentioned here, but I think all of these leave handling of external fortran/C/C++ source packages to other systems. This makes sense for large projects such as Qt. However, for new D programmers, original C sources may slowly disappear over time while continuing to supply key functionality for quite a while and I presume that getting new programmers is a central goal of the community.
>
> Since dub already works with compilers other than dmd, how much work would it take to make it work with other llvm/gcc supported languages such as fortran/c/c++ ?
>
> Are there fundamental non-technical reasons that support for selected external languages in dub is a bad idea?
>
> Maybe these are naive questions.
>
> I found dub to be especially handy in the wild-west environment of Windows programming and would like to rely on it a bit more.
>
> Kind Regards,

On Friday, 19 March 2021 at 23:30:10 UTC, Eugen Wissner wrote:

> ... dub is more of a package
> manager with some build system capabilities than a build system.

Ah, that makes it more clear.  This is a very handy combo by the way, especially on Windows where package managers and build tools can't implicitly communicate with each other via a standard filesystem layout.

> In my opinion it would be better to add D support to existing build systems. Meson supported D, there were cmake intergration for D.

I've been working with meson today.  Meson has the opposite problem, it's a build system that can kinda sorta do some package wrangling.  Meson and cmake look like they only address half of the problem space.

I don't know what problems dub has that people considered re-writing it, but it sure is a handy starter tool, much gentler learning curve then maven.

On Friday, 19 March 2021 at 23:11:51 UTC, Chris Piker wrote:
> I am curious to know what barriers prevent dub from supporting C source code compilation.

The best option currently is probably to call any existing build tool in dub’s preBuildCommands to compile files in foreign languages as part of the dub build process.

Do you see any issues using this approach?

— Bastiaan.

On Saturday, 20 March 2021 at 14:19:25 UTC, Bastiaan Veelo wrote:
> On Friday, 19 March 2021 at 23:11:51 UTC, Chris Piker wrote:
>> I am curious to know what barriers prevent dub from supporting C source code compilation.
>
> The best option currently is probably to call any existing build tool in dub’s preBuildCommands to compile files in foreign languages as part of the dub build process.
>
> Do you see any issues using this approach?
>
> — Bastiaan.

This is probably what I would do if I had to

On 3/20/21 10:28 AM, Imperatorn wrote:
> On Saturday, 20 March 2021 at 14:19:25 UTC, Bastiaan Veelo wrote:
>> On Friday, 19 March 2021 at 23:11:51 UTC, Chris Piker wrote:
>>> I am curious to know what barriers prevent dub from supporting C source code compilation.
>>
>> The best option currently is probably to call any existing build tool in dub’s preBuildCommands to compile files in foreign languages as part of the dub build process.
>>
>> Do you see any issues using this approach?
>>
>> — Bastiaan.
> 
> This is probably what I would do if I had to

Yes, this is what we do for our D library that needs some C source linked in as .o file. I posted a followup to Chris' message in the learn forum as well.

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

On Saturday, 20 March 2021 at 14:19:25 UTC, Bastiaan Veelo wrote:
> On Friday, 19 March 2021 at 23:11:51 UTC, Chris Piker wrote:
>> I am curious to know what barriers prevent dub from supporting C source code compilation.
>
> The best option currently is probably to call any existing build tool in dub’s preBuildCommands to compile files in foreign languages as part of the dub build process.
>
> Do you see any issues using this approach?
>
> — Bastiaan.

Hey thanks for the advice.  I agree it's the current best option. I was afraid that putting C sources into dub packages would violate community norms but that seems to be acceptable, at least occasionally.

Getting back to the broader topic, here's another way to state the original question:

  Suppose someone had a dub fork that supported C/C++ code well.
  Would a pull request to merge that support be rejected out of hand?

What I'm trying to find out is if the problem of closely related language support is technical, or for lack of a better word, philosophical.  What I'm hearing is that dub doesn't support C/C++ code for two reasons:

 1. It's a bad idea. (main reason)
 2. There's no resources for such an effort. (secondary concern)

Does that sound correct?

On 23/03/2021 5:22 PM, Chris Piker wrote:
> is technical, or for lack of a better word, philosophical.

Entirely philosophical.

It would be nice to get something like premake to support dub packages and maybe have it hook back into dub so they can feed into each other (although premake side may have to be manual).