www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Does D need standard locations?

reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
Hi,

Next list of things that need sorting out™ in GDC is how the compiler
works out where module interfaces are installed vs. where the library
actually installed them - this is tricky when taking into
consideration:

- There may be multiple versions installed.
- It may be a cross compiler.
- It may support multiarch/multilib configuration (-m32, -mx32, -m64).
- The compiler may have been relocated (Think 'DESTDIR=/relocate make install')

Traditionally, we've gone for the following two locations to look for
D sources (ignoring cross compilers for the moment).

/usr/include/d/$(version)
/usr/include/d/$(version)/$(target)/$(multilib)

And satisfying all considerations with the above structure has been a
challenge with some clever script tomfoolery to make it *look* like
the compiler build and library configure scripts are in parity.

So, I aim to fix that, and the first point of reference to go for
without making additional patches to gcc is to re-use C's header
structure, tacing "/d" on the end.

First draft is in this branch here:
https://github.com/ibuclaw/GDC/compare/fix_includes

Which changes the search paths to the following locations (expanded
out all /../'s to make it readable):

/usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
/usr/local/include/d/$(multilib)
/usr/lib/gcc/$(host)/$(version)/include-fixed/d
/usr/$(target)/include/d
/usr/include/d

While it is quite clear that druntime/phobos sources shipped with GDC
will soon be installed in the library directories.  This introduces
some interesting new behaviours (if you're not running Windows, at
least).  Suddenly, you can install a D source file in any of the
system, local, or target include directories, and it will be
automatically picked up by the compiler.

However, this may not be a good thing.  The way we are going with
dealing with D libraries - it looks like the only way is Dub and
introducing this *now* brings nothing to the table.

And even if Dub isn't your first choice of package system, then you'd
probably still not care in the slightest as we're all now so far in
being used to not following in the C/C++ tradition of library
installations, each and every one of us (and our dog) has likely
invented our own scheme that suits us, then changed the configuration,
or did a bespoke build to match your set-up.

Regardless, this is much better for GDC, and allows for hundreds of
deletions in scripts to follow, not to mention offloading the logic of
*where* things should be installed back to GCC.  So for the time
being, we say 'Hello' to the traditional idioms of last century, and
see what abuse scales from there.

Iain.
Feb 01 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 February 2015 at 18:58:22 UTC, Iain Buclaw wrote:

 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32, 
 -m64).


AFAIU those are effectively non-existent in D and expected to be 
handled with internal version blocks, not file system 
differentiation during installation.


 - The compiler may have been relocated (Think 
 'DESTDIR=/relocate make install')


Why does it matter?


 Traditionally, we've gone for the following two locations to 
 look for
 D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)


I use simply /usr/include/dlang/<compiler-name> in Arch for now 
(because versions are irrelevant for bleeding edge distro and 
target seems irrelevant to D in general).

Most likely will keep it that way even if upstream layout changes 
because there is simply no practical reason in overcomplicating 
it gcc-style. Not right now. Unless see some very complelling 
arguments of course :)


 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)


What kind of modules would you put here?


 Suddenly, you can install a D source file in any of the
 system, local, or target include directories, and it will be
 automatically picked up by the compiler.


I don't think magical addition of /usr/local import paths without 
explicit user request is good thing.


 However, this may not be a good thing.  The way we are going 
 with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.


Import distinction from C world distribution model is that with D 
source-based library distribution is generally more useful than 
precompiled library + bindings. Mostly because of all extra 
optimization possibilities and wide template usage.


 Regardless, this is much better for GDC, and allows for 
 hundreds of
 deletions in scripts to follow, not to mention offloading the 
 logic of
 *where* things should be installed back to GCC.  So for the time
 being, we say 'Hello' to the traditional idioms of last 
 century, and
 see what abuse scales from there.


Could you please give a quick overview of how it was supposed to 
work for now? :)
Feb 01 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 Feb 2015 21:50, "Dicebot via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Sunday, 1 February 2015 at 18:58:22 UTC, Iain Buclaw wrote:

 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32, -m64).



 AFAIU those are effectively non-existent in D and expected to be handled


with internal version blocks, not file system differentiation during
installation.


These details probably only matter to a package maintainer.  And is more a
result of how gcc works, as opposed to intentional design.


 - The compiler may have been relocated (Think 'DESTDIR=/relocate make




install')

 Why does it matter?


You can move the installation anywhere and it continues to just work, and
figure out where everything is located.


 Traditionally, we've gone for the following two locations to look for
 D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)



 I use simply /usr/include/dlang/<compiler-name> in Arch for now (because


versions are irrelevant for bleeding edge distro and target seems
irrelevant to D in general).

 Most likely will keep it that way even if upstream layout changes because


there is simply no practical reason in overcomplicating it gcc-style. Not
right now. Unless see some very complelling arguments of course :)

 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)



 What kind of modules would you put here?


Everything - as in Druntime and Phobos.  Rational being that they are
compiler specific, and so a private location relevant to the compiler seems
fitting.


 Suddenly, you can install a D source file in any of the
 system, local, or target include directories, and it will be
 automatically picked up by the compiler.



 I don't think magical addition of /usr/local import paths without


explicit user request is good thing.

 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.



 Import distinction from C world distribution model is that with D


source-based library distribution is generally more useful than precompiled
library + bindings. Mostly because of all extra optimization possibilities
and wide template usage.

 Regardless, this is much better for GDC, and allows for hundreds of
 deletions in scripts to follow, not to mention offloading the logic of
 *where* things should be installed back to GCC.  So for the time
 being, we say 'Hello' to the traditional idioms of last century, and
 see what abuse scales from there.



 Could you please give a quick overview of how it was supposed to work for


now? :)

Now or future?



 Feb 01 2015



prev sibling next sibling parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Sun, 01 Feb 2015 18:58:03 +0000, Iain Buclaw via Digitalmars-d wrote:

unification is great. and seems that nobody else cares anyway, so let it=20
be "GCC-way" then. ;-)=



 Feb 01 2015



prev sibling next sibling parent reply Johannes Pfau <nospam example.com>  writes:


Am Sun, 1 Feb 2015 18:58:03 +0000
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 Hi,
=20
 Next list of things that need sorting out=E2=84=A2 in GDC is how the comp=


iler

 works out where module interfaces are installed vs. where the library
 actually installed them - this is tricky when taking into
 consideration:
=20
 - There may be multiple versions installed.
 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32, -m64).
 - The compiler may have been relocated (Think 'DESTDIR=3D/relocate make
 install')
=20
 Traditionally, we've gone for the following two locations to look for
 D sources (ignoring cross compilers for the moment).
=20
 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)
=20
 And satisfying all considerations with the above structure has been a
 challenge with some clever script tomfoolery to make it *look* like
 the compiler build and library configure scripts are in parity.
=20
 So, I aim to fix that, and the first point of reference to go for
 without making additional patches to gcc is to re-use C's header
 structure, tacing "/d" on the end.
=20
 First draft is in this branch here:
 https://github.com/ibuclaw/GDC/compare/fix_includes
=20
 Which changes the search paths to the following locations (expanded
 out all /../'s to make it readable):
=20
 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
 /usr/local/include/d/$(multilib)
 /usr/lib/gcc/$(host)/$(version)/include-fixed/d
 /usr/$(target)/include/d
 /usr/include/d
=20
 While it is quite clear that druntime/phobos sources shipped with GDC
 will soon be installed in the library directories.  This introduces
 some interesting new behaviours (if you're not running Windows, at
 least).  Suddenly, you can install a D source file in any of the
 system, local, or target include directories, and it will be
 automatically picked up by the compiler.
=20
 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.
=20
 And even if Dub isn't your first choice of package system, then you'd
 probably still not care in the slightest as we're all now so far in
 being used to not following in the C/C++ tradition of library
 installations, each and every one of us (and our dog) has likely
 invented our own scheme that suits us, then changed the configuration,
 or did a bespoke build to match your set-up.
=20
 Regardless, this is much better for GDC, and allows for hundreds of
 deletions in scripts to follow, not to mention offloading the logic of
 *where* things should be installed back to GCC.  So for the time
 being, we say 'Hello' to the traditional idioms of last century, and
 see what abuse scales from there.
=20
 Iain.
=20


Sounds good, I think the fact that we need dub to build anything is not
a feature but rather embarrassing. A layout as in C++ with a
system-wide include directory makes sense. The real problem is actually
with libraries as long as compilers are not ABI compatible. We can't
really do anything about that though. While static libraries could be
moved to different folder (like dub does) this approach doesn't work
for shared libraries.

include-fixed is kinda C++ specific though, how would we use that for
D headers?



 Feb 02 2015



 next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Sun, 1 Feb 2015 18:58:03 +0000
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 Hi,

 Next list of things that need sorting out™ in GDC is how the compiler
 works out where module interfaces are installed vs. where the library
 actually installed them - this is tricky when taking into
 consideration:

 - There may be multiple versions installed.
 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32, -m64).
 - The compiler may have been relocated (Think 'DESTDIR=/relocate make
 install')

 Traditionally, we've gone for the following two locations to look for
 D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)

 And satisfying all considerations with the above structure has been a
 challenge with some clever script tomfoolery to make it *look* like
 the compiler build and library configure scripts are in parity.

 So, I aim to fix that, and the first point of reference to go for
 without making additional patches to gcc is to re-use C's header
 structure, tacing "/d" on the end.

 First draft is in this branch here:
 https://github.com/ibuclaw/GDC/compare/fix_includes

 Which changes the search paths to the following locations (expanded
 out all /../'s to make it readable):

 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
 /usr/local/include/d/$(multilib)
 /usr/lib/gcc/$(host)/$(version)/include-fixed/d
 /usr/$(target)/include/d
 /usr/include/d

 While it is quite clear that druntime/phobos sources shipped with GDC
 will soon be installed in the library directories.  This introduces
 some interesting new behaviours (if you're not running Windows, at
 least).  Suddenly, you can install a D source file in any of the
 system, local, or target include directories, and it will be
 automatically picked up by the compiler.

 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.

 And even if Dub isn't your first choice of package system, then you'd
 probably still not care in the slightest as we're all now so far in
 being used to not following in the C/C++ tradition of library
 installations, each and every one of us (and our dog) has likely
 invented our own scheme that suits us, then changed the configuration,
 or did a bespoke build to match your set-up.

 Regardless, this is much better for GDC, and allows for hundreds of
 deletions in scripts to follow, not to mention offloading the logic of
 *where* things should be installed back to GCC.  So for the time
 being, we say 'Hello' to the traditional idioms of last century, and
 see what abuse scales from there.

 Iain.


 Sounds good, I think the fact that we need dub to build anything is not
 a feature but rather embarrassing. A layout as in C++ with a
 system-wide include directory makes sense. The real problem is actually
 with libraries as long as compilers are not ABI compatible. We can't
 really do anything about that though. While static libraries could be
 moved to different folder (like dub does) this approach doesn't work
 for shared libraries.

 include-fixed is kinda C++ specific though, how would we use that for
 D headers?


I guess maybe for gcc-specific C bindings?  In any case nothing that
can't be fixed with versioning.



 Feb 02 2015



prev sibling  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Am Sun, 1 Feb 2015 18:58:03 +0000
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 Hi,

 Next list of things that need sorting out™ in GDC is how the compiler
 works out where module interfaces are installed vs. where the library
 actually installed them - this is tricky when taking into
 consideration:

 - There may be multiple versions installed.
 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32, -m64).
 - The compiler may have been relocated (Think 'DESTDIR=/relocate make
 install')

 Traditionally, we've gone for the following two locations to look for
 D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)

 And satisfying all considerations with the above structure has been a
 challenge with some clever script tomfoolery to make it *look* like
 the compiler build and library configure scripts are in parity.

 So, I aim to fix that, and the first point of reference to go for
 without making additional patches to gcc is to re-use C's header
 structure, tacing "/d" on the end.

 First draft is in this branch here:
 https://github.com/ibuclaw/GDC/compare/fix_includes

 Which changes the search paths to the following locations (expanded
 out all /../'s to make it readable):

 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
 /usr/local/include/d/$(multilib)
 /usr/lib/gcc/$(host)/$(version)/include-fixed/d
 /usr/$(target)/include/d
 /usr/include/d

 While it is quite clear that druntime/phobos sources shipped with GDC
 will soon be installed in the library directories.  This introduces
 some interesting new behaviours (if you're not running Windows, at
 least).  Suddenly, you can install a D source file in any of the
 system, local, or target include directories, and it will be
 automatically picked up by the compiler.

 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.

 And even if Dub isn't your first choice of package system, then you'd
 probably still not care in the slightest as we're all now so far in
 being used to not following in the C/C++ tradition of library
 installations, each and every one of us (and our dog) has likely
 invented our own scheme that suits us, then changed the configuration,
 or did a bespoke build to match your set-up.

 Regardless, this is much better for GDC, and allows for hundreds of
 deletions in scripts to follow, not to mention offloading the logic of
 *where* things should be installed back to GCC.  So for the time
 being, we say 'Hello' to the traditional idioms of last century, and
 see what abuse scales from there.

 Iain.


 Sounds good, I think the fact that we need dub to build anything is not
 a feature but rather embarrassing. A layout as in C++ with a
 system-wide include directory makes sense. The real problem is actually
 with libraries as long as compilers are not ABI compatible. We can't
 really do anything about that though. While static libraries could be
 moved to different folder (like dub does) this approach doesn't work
 for shared libraries.

 include-fixed is kinda C++ specific though, how would we use that for
 D headers?


 I guess maybe for gcc-specific C bindings?  In any case nothing that
 can't be fixed with versioning.


The alternative to my patch above is to just use one location for everything:

$(libsubdir)/include/d

Which guarantees to have the target and version directories to
separate it from any other gdc installations.

Iain



 Feb 02 2015



 next sibling parent reply Johannes Pfau <nospam example.com>  writes:


Am Mon, 2 Feb 2015 13:24:09 +0000
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw gdcproject.org>
 wrote:

 On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Am Sun, 1 Feb 2015 18:58:03 +0000
 schrieb Iain Buclaw via Digitalmars-d
 <digitalmars-d puremagic.com>:


 Hi,

 Next list of things that need sorting out=E2=84=A2 in GDC is how the
 compiler works out where module interfaces are installed vs.
 where the library actually installed them - this is tricky when
 taking into consideration:

 - There may be multiple versions installed.
 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32,
 -m64).
 - The compiler may have been relocated (Think 'DESTDIR=3D/relocate
 make install')

 Traditionally, we've gone for the following two locations to look
 for D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)

 And satisfying all considerations with the above structure has
 been a challenge with some clever script tomfoolery to make it
 *look* like the compiler build and library configure scripts are
 in parity.

 So, I aim to fix that, and the first point of reference to go for
 without making additional patches to gcc is to re-use C's header
 structure, tacing "/d" on the end.

 First draft is in this branch here:
 https://github.com/ibuclaw/GDC/compare/fix_includes

 Which changes the search paths to the following locations
 (expanded out all /../'s to make it readable):

 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
 /usr/local/include/d/$(multilib)
 /usr/lib/gcc/$(host)/$(version)/include-fixed/d
 /usr/$(target)/include/d
 /usr/include/d

 While it is quite clear that druntime/phobos sources shipped with
 GDC will soon be installed in the library directories.  This
 introduces some interesting new behaviours (if you're not running
 Windows, at least).  Suddenly, you can install a D source file in
 any of the system, local, or target include directories, and it
 will be automatically picked up by the compiler.

 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.

 And even if Dub isn't your first choice of package system, then
 you'd probably still not care in the slightest as we're all now
 so far in being used to not following in the C/C++ tradition of
 library installations, each and every one of us (and our dog) has
 likely invented our own scheme that suits us, then changed the
 configuration, or did a bespoke build to match your set-up.

 Regardless, this is much better for GDC, and allows for hundreds
 of deletions in scripts to follow, not to mention offloading the
 logic of *where* things should be installed back to GCC.  So for
 the time being, we say 'Hello' to the traditional idioms of last
 century, and see what abuse scales from there.

 Iain.


 Sounds good, I think the fact that we need dub to build anything
 is not a feature but rather embarrassing. A layout as in C++ with a
 system-wide include directory makes sense. The real problem is
 actually with libraries as long as compilers are not ABI
 compatible. We can't really do anything about that though. While
 static libraries could be moved to different folder (like dub
 does) this approach doesn't work for shared libraries.

 include-fixed is kinda C++ specific though, how would we use that
 for D headers?


 I guess maybe for gcc-specific C bindings?  In any case nothing that
 can't be fixed with versioning.


=20
 The alternative to my patch above is to just use one location for
 everything:
=20
 $(libsubdir)/include/d
=20
 Which guarantees to have the target and version directories to
 separate it from any other gdc installations.
=20
 Iain
=20


I'd prefer the other scheme.
In the end it's simple enough to not store any D headers in /usr if you
don't want GDC to include them.

But having a standard location makes many things easier.
apt-get install msgpack-d then opening MonoDevelop, simply importing
msgpack without ever adding include paths and compiling requires only
adding only a single -lmsgpack, ...



 Feb 02 2015



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 February 2015 at 17:22, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Mon, 2 Feb 2015 13:24:09 +0000
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw gdcproject.org>
 wrote:

 On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Am Sun, 1 Feb 2015 18:58:03 +0000
 schrieb Iain Buclaw via Digitalmars-d
 <digitalmars-d puremagic.com>:


 Hi,

 Next list of things that need sorting out™ in GDC is how the
 compiler works out where module interfaces are installed vs.
 where the library actually installed them - this is tricky when
 taking into consideration:

 - There may be multiple versions installed.
 - It may be a cross compiler.
 - It may support multiarch/multilib configuration (-m32, -mx32,
 -m64).
 - The compiler may have been relocated (Think 'DESTDIR=/relocate
 make install')

 Traditionally, we've gone for the following two locations to look
 for D sources (ignoring cross compilers for the moment).

 /usr/include/d/$(version)
 /usr/include/d/$(version)/$(target)/$(multilib)

 And satisfying all considerations with the above structure has
 been a challenge with some clever script tomfoolery to make it
 *look* like the compiler build and library configure scripts are
 in parity.

 So, I aim to fix that, and the first point of reference to go for
 without making additional patches to gcc is to re-use C's header
 structure, tacing "/d" on the end.

 First draft is in this branch here:
 https://github.com/ibuclaw/GDC/compare/fix_includes

 Which changes the search paths to the following locations
 (expanded out all /../'s to make it readable):

 /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
 /usr/local/include/d/$(multilib)
 /usr/lib/gcc/$(host)/$(version)/include-fixed/d
 /usr/$(target)/include/d
 /usr/include/d

 While it is quite clear that druntime/phobos sources shipped with
 GDC will soon be installed in the library directories.  This
 introduces some interesting new behaviours (if you're not running
 Windows, at least).  Suddenly, you can install a D source file in
 any of the system, local, or target include directories, and it
 will be automatically picked up by the compiler.

 However, this may not be a good thing.  The way we are going with
 dealing with D libraries - it looks like the only way is Dub and
 introducing this *now* brings nothing to the table.

 And even if Dub isn't your first choice of package system, then
 you'd probably still not care in the slightest as we're all now
 so far in being used to not following in the C/C++ tradition of
 library installations, each and every one of us (and our dog) has
 likely invented our own scheme that suits us, then changed the
 configuration, or did a bespoke build to match your set-up.

 Regardless, this is much better for GDC, and allows for hundreds
 of deletions in scripts to follow, not to mention offloading the
 logic of *where* things should be installed back to GCC.  So for
 the time being, we say 'Hello' to the traditional idioms of last
 century, and see what abuse scales from there.

 Iain.


 Sounds good, I think the fact that we need dub to build anything
 is not a feature but rather embarrassing. A layout as in C++ with a
 system-wide include directory makes sense. The real problem is
 actually with libraries as long as compilers are not ABI
 compatible. We can't really do anything about that though. While
 static libraries could be moved to different folder (like dub
 does) this approach doesn't work for shared libraries.

 include-fixed is kinda C++ specific though, how would we use that
 for D headers?


 I guess maybe for gcc-specific C bindings?  In any case nothing that
 can't be fixed with versioning.


 The alternative to my patch above is to just use one location for
 everything:

 $(libsubdir)/include/d

 Which guarantees to have the target and version directories to
 separate it from any other gdc installations.

 Iain


 I'd prefer the other scheme.
 In the end it's simple enough to not store any D headers in /usr if you
 don't want GDC to include them.

 But having a standard location makes many things easier.
 apt-get install msgpack-d then opening MonoDevelop, simply importing
 msgpack without ever adding include paths and compiling requires only
 adding only a single -lmsgpack, ...


OK - going to plough ahead with updating libphobos configure scripts then.

By the way, any last word on https://github.com/D-Programming-GDC/GDC/pull/92 ?

Iain.



 Feb 02 2015



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


My attitude to any such changes in general is "I don't care as 
long as I can easily override it with own patches before 
packaging gdc".

In practice distro are simply too different to try fitting 
everything into single pattern. In Arch Linux it is prohibited to 
package source-only libraries and thus dub is pretty much a 
necessity. At the same time being a bleeding edge distro it 
doesn't care for simultaneous support of many compiler versions 
at once and all that infrastructure can be dropped to keep things 
KISS.

So, please, whatever you do, keep it easy for packager to 
override all paths :)



 Feb 02 2015



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 February 2015 at 17:44, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 My attitude to any such changes in general is "I don't care as long as I can
 easily override it with own patches before packaging gdc".

 In practice distro are simply too different to try fitting everything into
 single pattern. In Arch Linux it is prohibited to package source-only
 libraries and thus dub is pretty much a necessity. At the same time being a
 bleeding edge distro it doesn't care for simultaneous support of many
 compiler versions at once and all that infrastructure can be dropped to keep
 things KISS.

 So, please, whatever you do, keep it easy for packager to override all paths
 :)


It's now a one-line change to stick it where-ever you want. Couldn't
be easier. :)

Iain.



 Feb 02 2015



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 2 February 2015 at 17:49:07 UTC, Iain Buclaw wrote:

 So, please, whatever you do, keep it easy for packager to 
 override all paths
 :)


 It's now a one-line change to stick it where-ever you want. 
 Couldn't
 be easier. :)

 Iain.


Yay, thanks! ^_^



 Feb 02 2015



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 February 2015 at 17:52, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 2 February 2015 at 17:49:07 UTC, Iain Buclaw wrote:

 So, please, whatever you do, keep it easy for packager to override all
 paths
 :)



 It's now a one-line change to stick it where-ever you want. Couldn't
 be easier. :)

 Iain.



 Yay, thanks! ^_^


Correction, two line change.  I momentarily forgot about the compiler
Make-lang.in  :)



 Feb 02 2015



  parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 2 February 2015 at 17:59:43 UTC, Iain Buclaw wrote:

 Correction, two line change.  I momentarily forgot about the 
 compiler
 Make-lang.in  :)


Will those be roughly the same lines as I tweak in 
https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff 
right now?



 Feb 02 2015



prev sibling  parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Monday, 2 February 2015 at 17:44:53 UTC, Dicebot wrote:

 In Arch Linux it is prohibited to package source-only libraries


How do they handle boost?



 Feb 03 2015



  parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 3 February 2015 at 11:51:31 UTC, Joseph Rushton
Wakeling wrote:

 On Monday, 2 February 2015 at 17:44:53 UTC, Dicebot wrote:

 In Arch Linux it is prohibited to package source-only libraries


 How do they handle boost?


Boost does provide prebuild static libraries, despite being
template-heavy - thus it still fits allowed "library + bindings"
model. It is not very suitable for D though.

On a related topic,  Iain, does using static libraries still
prevent inlining in gdc?



 Feb 03 2015



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2015-02-01 19:58, Iain Buclaw via Digitalmars-d wrote:

 Hi,

 Next list of things that need sorting out™ in GDC is how the compiler
 works out where module interfaces are installed vs. where the library
 actually installed them - this is tricky when taking into
 consideration:


I don't know if this matters but eventually I would like to add support 
for GDC in DVM. Installing multiple versions of DMD in any directory I 
want is very easy since DMD has a self contained zip and dmd.conf.

Placing files all over the system sounds like it will make adding 
support in DVM harder.

-- 
/Jacob Carlborg



 Feb 03 2015



  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Tue, 03 Feb 2015 20:46:55 +0100, Jacob Carlborg wrote:


 On 2015-02-01 19:58, Iain Buclaw via Digitalmars-d wrote:

 Hi,

 Next list of things that need sorting out=E2=84=A2 in GDC is how the com=




piler

 works out where module interfaces are installed vs. where the library
 actually installed them - this is tricky when taking into
 consideration:


=20
 I don't know if this matters but eventually I would like to add support
 for GDC in DVM. Installing multiple versions of DMD in any directory I
 want is very easy since DMD has a self contained zip and dmd.conf.
=20
 Placing files all over the system sounds like it will make adding
 support in DVM harder.


adding support for "-nostdinc" and "-isystem" to gdc should allow=20
replacing pathes. or maybe it already supports that, i don't know...=



 Feb 03 2015