On (my version of) Linux, gdc has an official apt repository, but there also exists a download page with what appears to be a much more recent version of gdc. So..which one should I use? I'd like to have pre-built binaries for my library ready to go for users, but I'm not sure which one I should build with.

Right now I am leaning towards the one on the download page due to updates, bug fixes, etc, but many people will presumably use whats in apt.

Suggestions?

Am Thu, 24 Sep 2015 03:07:53 +0000
schrieb Jeremy DeHaan <dehaan.jeremiah@gmail.com>:

> On (my version of) Linux, gdc has an official apt repository, but there also exists a download page with what appears to be a much more recent version of gdc. So..which one should I use? I'd like to have pre-built binaries for my library ready to go for users, but I'm not sure which one I should build with.
> 
> Right now I am leaning towards the one on the download page due to updates, bug fixes, etc, but many people will presumably use whats in apt.
> 
> Suggestions?

The downloads from gdcproject.org/downloads provide more recent frontend (<=> DMD) versions. The frontend introduces new features in the language, so most D projects require very recent frontend versions. Even the latest available GDC version right now (2.066) is two versions behind DMD (2.068). The debian packages usually provide even older frontend versions.

So if you use code which requires a newer frontend version you'll have to use the downloads from gdcproject.org. Otherwise you can look up the changelog here to check if you need/want any of the features or bugfixes in newer frontends: http://dlang.org/changelog/index.html

The other version is the GCC version. While newer GCC versions might produce better optimized code (https://gcc.gnu.org/gcc-5/changes.html) we recommend using the same GCC version as used by your Linux distribution. The main reason for this is that there might be cases where newer GCC versions are not compatible with older GDB versions. However, you can usually use any GCC version.

Generally speaking distribution packages are easier to support as they're built explicitly for one Linux distribution. The packages from gdcproject.org have to work on many Linux versions which sometimes can be difficult (if your distribution installs libraries into unusual directories, the compiler might not find them, ...). However, we haven't really heard about problems with the packages from gdcproject.org, so they should work fine for most distributions.


BTW: Shipping prebuilt D libraries is uncommon. The main compilers (gdc/dmd/ldc) do not produce compatible libraries. Libraries compiled with other frontend versions are usually not compatible even when compiled with the same compiler. If you want to provide binaries most people will probably use the newest frontend version, so I'd say use the version from gdcproject.org

On Thursday, 24 September 2015 at 10:21:03 UTC, Johannes Pfau wrote:
> Am Thu, 24 Sep 2015 03:07:53 +0000
> schrieb Jeremy DeHaan <dehaan.jeremiah@gmail.com>:

Thanks for the info. That was pretty much what I thought.

> BTW: Shipping prebuilt D libraries is uncommon. The main compilers (gdc/dmd/ldc) do not produce compatible libraries. Libraries compiled with other frontend versions are usually not compatible even when compiled with the same compiler. If you want to provide binaries most people will probably use the newest frontend version, so I'd say use the version from gdcproject.org

Is it that uncommon? I was aware they were incompatible between frontends, so I was going to have two for each (32 and 64) and label which frontend/compiler version they were built with. I figure that will cover most people if they don't want to bother building them, but I'll also make it easy for those that need/want to build them.

On 27 Sep 2015 12:05 am, "Jeremy DeHaan via D.gnu" <d.gnu@puremagic.com> wrote:
>
> On Thursday, 24 September 2015 at 10:21:03 UTC, Johannes Pfau wrote:
>>
>> Am Thu, 24 Sep 2015 03:07:53 +0000
>> schrieb Jeremy DeHaan <dehaan.jeremiah@gmail.com>:
>
>
> Thanks for the info. That was pretty much what I thought.
>
>
>> BTW: Shipping prebuilt D libraries is uncommon. The main compilers
(gdc/dmd/ldc) do not produce compatible libraries. Libraries compiled with other frontend versions are usually not compatible even when compiled with the same compiler. If you want to provide binaries most people will probably use the newest frontend version, so I'd say use the version from gdcproject.org
>
>
> Is it that uncommon? I was aware they were incompatible between
frontends, so I was going to have two for each (32 and 64) and label which frontend/compiler version they were built with. I figure that will cover most people if they don't want to bother building them, but I'll also make it easy for those that need/want to build them.

The more 'common' thing to do nowadays is to hook your library into dub. No need to provide binaries of the library.

http://code.dlang.org

Iain.

On Sunday, 27 September 2015 at 06:03:00 UTC, Iain Buclaw wrote:

> The more 'common' thing to do nowadays is to hook your library into dub. No need to provide binaries of the library.
>


Oh, I do both. This is just for the people that don't use dub.

On Monday, 28 September 2015 at 00:53:57 UTC, Jeremy DeHaan wrote:
> On Sunday, 27 September 2015 at 06:03:00 UTC, Iain Buclaw wrote:
>
>> The more 'common' thing to do nowadays is to hook your library into dub. No need to provide binaries of the library.
>>
>
>
> Oh, I do both. This is just for the people that don't use dub.

Why not offer a source download with a dub binary (or even sources for dub, it's only 5 seconds in one ./build.sh from being a binary...)? The user doesn't even have to know they're using dub.