Thread overview
Where is ldc.gccbuiltins_x86?
Jan 20, 2016
Iakh
Jan 20, 2016
David Nadlinger
Jan 20, 2016
Iakh
Jan 20, 2016
David Nadlinger
Jan 21, 2016
Dicebot
Jan 21, 2016
David Nadlinger
Jan 21, 2016
Dicebot
Jan 22, 2016
David Nadlinger
Jan 22, 2016
Dicebot
January 20, 2016
I'm trying to do

import ldc.gccbuiltins_x86;

but there is no such module
Error: module gccbuiltins_x86 is in file 'ldc/gccbuiltins_x86.d' which cannot be read
import path[0] = /usr/include/dlang/ldc/ldc
import path[1] = /usr/include/dlang/ldc
import path[2] = .
ldc failed with exit code 1.

LDC - the LLVM D compiler (0.16.1):
based on DMD v2.067.1 and LLVM 3.7.0

Is there a way to use gccbuiltins (sse2 intrinsics)?
January 20, 2016
On 20 Jan 2016, at 3:36, Iakh via digitalmars-d-ldc wrote:
> I'm trying to do
>
> import ldc.gccbuiltins_x86;
>
> but there is no such module

How did you install LDC? It is supposed to be generated during the LDC build process (${CMAKE_BINARY_DIR}/runtime/gccbuiltins_x86.di) and then copied into ${INCLUDE_INSTALL_DIR}/ldc as part of the installation phase.

 — David
January 20, 2016
On Wednesday, 20 January 2016 at 15:53:30 UTC, David Nadlinger wrote:
> How did you install LDC?
>  — David

It's standard package of Arch Linux. I had installed it with pacman.
So if the file is missing is it problem of the packege?
January 20, 2016
On 20 Jan 2016, at 17:31, Iakh via digitalmars-d-ldc wrote:>
> It's standard package of Arch Linux. I had installed it with pacman.
> So if the file is missing is it problem of the packege?

Yes. I just had a look at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD, and it seems to manually copy over all the files instead of using the CMake install target. $srcdir/ldc/build/runtime/gccbuiltins*.di seems to be missing from that list.

 — David
January 21, 2016
On Wednesday, 20 January 2016 at 16:41:47 UTC, David Nadlinger wrote:
> On 20 Jan 2016, at 17:31, Iakh via digitalmars-d-ldc wrote:>
>> It's standard package of Arch Linux. I had installed it with pacman.
>> So if the file is missing is it problem of the packege?
>
> Yes. I just had a look at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD, and it seems to manually copy over all the files instead of using the CMake install target. $srcdir/ldc/build/runtime/gccbuiltins*.di seems to be missing from that list.
>
>  — David

btw I wouldn't be able to use cmake install target even if I wanted (I always try to avoid that) because with current CMakeLists.txt it uses system path to bash-completion directory coming from `find_package` and not one inside prefix (unless I am missing another obscure cmake flag)

Updated package with gccbuiltins_x86.di will propagate to mirrors soon.
January 22, 2016
On 22 Jan 2016, at 0:07, Dicebot via digitalmars-d-ldc wrote:
> Updated package with gccbuiltins_x86.di will propagate to mirrors soon.

Thanks!

> btw I wouldn't be able to use cmake install target even if I wanted (I always try to avoid that) because with current CMakeLists.txt it uses system path to bash-completion directory coming from `find_package` and not one inside prefix (unless I am missing another obscure cmake flag)

You are of course free to package stuff in whatever way you find the easiest. But can't you just use "make install DESTDIR=…" like for pretty much every CMake or Autotools project to get exactly what you want? Pretty sure that's recommended in various Arch packaging guides too. If we install files outside that directory, it's definitely a bug in our CMake scripts.

 — David
January 21, 2016
On Thursday, 21 January 2016 at 23:18:59 UTC, David Nadlinger wrote:
> On 22 Jan 2016, at 0:07, Dicebot via digitalmars-d-ldc wrote:
>> Updated package with gccbuiltins_x86.di will propagate to mirrors soon.
>
> Thanks!
>
>> btw I wouldn't be able to use cmake install target even if I wanted (I always try to avoid that) because with current CMakeLists.txt it uses system path to bash-completion directory coming from `find_package` and not one inside prefix (unless I am missing another obscure cmake flag)
>
> You are of course free to package stuff in whatever way you find the easiest. But can't you just use "make install DESTDIR=…" like for pretty much every CMake or Autotools project to get exactly what you want? Pretty sure that's recommended in various Arch packaging guides too. If we install files outside that directory, it's definitely a bug in our CMake scripts.
>
>  — David

I tried using something akin to -DCMAKE_INSTALL_PREFIX=/path/to/pkg but it failed because of that mention bash-completion issue (tried to write to /usr/share/bash-completion).

Off-Topic Philosophy:

In general it is sort of my personal obsession that goes against usual approach :) I started to do it for two reasons:

1) it forces to learn something about internal project path/file organization (which fits my understanding of packager responsibilities)
2) it encourages to actually improve the layout to make it more fitting for specific distro and provide some useful additions (i.e. systemd service files)

Sometimes it results in "oops" moments like this one but I believe overall user experience gets improved a lot. Of course this approach is only viable if one maintains relatively small amount of packages.
January 22, 2016
On 22 Jan 2016, at 0:39, Dicebot via digitalmars-d-ldc wrote:
> I tried using something akin to -DCMAKE_INSTALL_PREFIX=/path/to/pkg but it failed because of that mention bash-completion issue (tried to write to /usr/share/bash-completion).

-DCMAKE_INSTALL_PREFIX=/path/to/pkg would prepare stuff to be installed to /path/to/pkg, which is not what you actually want for packaging. You wouldn't use --prefix=/path/to/pkg for an autotooled project either. For example, /path/to/pkg might end up being inserted into some config files that way. The bash-completion path issue is another manifestation of that – your system tells us that it wants the completion files in /usr/share/bash-completion, so we'll put them there by default.

DESTDIR is different. Its express purpose is to help with packaging (and similar scenarios like installing directly to a specially mounted chroot). For reference, see https://www.gnu.org/prep/standards/html_node/DESTDIR.html and https://wiki.archlinux.org/index.php/Arch_packaging_standards resp. https://wiki.archlinux.org/index.php/Creating_packages. You are doing an awesome job with LDC packaging – thank you! – so I don't doubt that the manual approach works for you. But maybe the usual automatic way will come in handy at some point. ;)

 — David
January 22, 2016
On Friday, 22 January 2016 at 00:23:30 UTC, David Nadlinger wrote:
> ..

Thanks! I simply checked some online manual for cmake (haven't used it myself, haven't even known it is in Arch guidelines!) and it mentioned this flag but I most likely have misunderstood its purpose :) Will keep DESTDIR in mind.