www.digitalmars.com         C & C++   DMDScript  

D.gnu - import problems

reply John Colvin <john.loughran.colvin gmail.com> writes:
Where does the information
Oct 13 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 13 October 2015 at 10:09:03 UTC, John Colvin wrote:

 Where does the information


sorry, pressed enter by accident.

What is the process by which gdc knows what the default import 
path for object.d is?

Alternatively, what do I have to change to choose my own location 
for gdc to install its imports to and have it automatically use 
that as an import path? I have seen 
https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff and
followed that example, but of course changing configure.ac is a pain because
then you have to have exactly the right version of autoconf to update
configure. Also, I couldn't find the relevant lines to change in
gcc/d/Make-lang.in

Currently I tried changing gdc_include_dir in the generated 
configure, which gets everything installed in the right place, 
but gdc doesn't import it (and doesn't show any import paths in 
the error message)
Oct 13 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 13 Oct 2015 10:16:11 +0000
schrieb John Colvin <john.loughran.colvin gmail.com>:


 On Tuesday, 13 October 2015 at 10:09:03 UTC, John Colvin wrote:

 Where does the information  


 
 sorry, pressed enter by accident.
 
 What is the process by which gdc knows what the default import 
 path for object.d is?
 


It uses all standard C include paths (/usr/inlcude, ...) and adds /d
at the end of the path.

It might additionally add multilib path variants (/usr/include/d/32).

(In practice it's more complicated to also support 'relocated'
compilers. GCC remembers the full path at compilation time but if you
move the gdc executable it will replace the paths prefix. I don't
remember how it works exactly.)


 Alternatively, what do I have to change to choose my own location 
 for gdc to install its imports to and have it automatically use 
 that as an import path? I have seen


Can't you just use --prefix when configuring? Ore use -I or the
D_IMPORT_PATH environment variable?

Anyway, the code you'll have to look at is here:
https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-incpath.cc

Look at add_import_paths, called from d_init in d-lang.cc

 

 https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff
 and followed that example, but of course changing configure.ac is a
 pain because then you have to have exactly the right version of
 autoconf to update configure. Also, I couldn't find the relevant
 lines to change in gcc/d/Make-lang.in


That code was refactored and the patch isn't valid anymore:
https://github.com/D-Programming-GDC/GDC/commit/5ea9c2a61d548d2edb65401cbb88c88b123aef53?w=0


 
 Currently I tried changing gdc_include_dir in the generated 
 configure, which gets everything installed in the right place, 
 but gdc doesn't import it (and doesn't show any import paths in 
 the error message)


Which error message exactly? Does DMD print the import path for these
errors?
Oct 14 2015
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 14 October 2015 at 22:08:25 UTC, Johannes Pfau 
wrote:

 Am Tue, 13 Oct 2015 10:16:11 +0000
 schrieb John Colvin <john.loughran.colvin gmail.com>:


 On Tuesday, 13 October 2015 at 10:09:03 UTC, John Colvin wrote:

 Where does the information


 
 sorry, pressed enter by accident.
 
 What is the process by which gdc knows what the default import 
 path for object.d is?
 


 It uses all standard C include paths (/usr/inlcude, ...) and 
 adds /d
 at the end of the path.

 It might additionally add multilib path variants 
 (/usr/include/d/32).

 (In practice it's more complicated to also support 'relocated' 
 compilers. GCC remembers the full path at compilation time but 
 if you move the gdc executable it will replace the paths 
 prefix. I don't remember how it works exactly.)


 Alternatively, what do I have to change to choose my own 
 location for gdc to install its imports to and have it 
 automatically use that as an import path? I have seen


 Can't you just use --prefix when configuring?


That deals with the prefix, but not the suffix.


 Ore use -I or the D_IMPORT_PATH environment variable?


I'm packaging GDC, so those aren't good solutions here.


 Anyway, the code you'll have to look at is here: 
 https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-incpath.cc

 Look at add_import_paths, called from d_init in d-lang.cc



 https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff and
followed that example, but of course changing configure.ac is a pain because
then you have to have exactly the right version of autoconf to update
configure. Also, I couldn't find the relevant lines to change in
gcc/d/Make-lang.in


 That code was refactored and the patch isn't valid anymore: 
 https://github.com/D-Programming-GDC/GDC/commit/5ea9c2a61d548d2edb65401cbb88c88b123aef53?w=0


So the /d suffix is hard-coded in to gdc? Can I just patch it to 
be whatever I want before compiling gdc or are there other places 
that would also need changing?


 
 Currently I tried changing gdc_include_dir in the generated 
 configure, which gets everything installed in the right place, 
 but gdc doesn't import it (and doesn't show any import paths 
 in the error message)


 Which error message exactly? Does DMD print the import path for 
 these errors?


I don't have the exact ones to hand right now, but it's the usual 
complaint about not being able to find object.d. When an import 
is missing, the compiler normally spits out a list of the include 
paths (same as in dmd, checked also with gdc on archlinux), but 
in this case it didn't print any.
Oct 14 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 15 Oct 2015 1:35 am, "John Colvin via D.gnu" <d.gnu puremagic.com> wrote:

 On Wednesday, 14 October 2015 at 22:08:25 UTC, Johannes Pfau wrote:

 Am Tue, 13 Oct 2015 10:16:11 +0000
 schrieb John Colvin <john.loughran.colvin gmail.com>:


 On Tuesday, 13 October 2015 at 10:09:03 UTC, John Colvin wrote:

 Where does the information


 sorry, pressed enter by accident.

 What is the process by which gdc knows what the default import path for






object.d is?


 It uses all standard C include paths (/usr/inlcude, ...) and adds /d
 at the end of the path.

 It might additionally add multilib path variants (/usr/include/d/32).

 (In practice it's more complicated to also support 'relocated'




compilers. GCC remembers the full path at compilation time but if you move
the gdc executable it will replace the paths prefix. I don't remember how
it works exactly.)




If I recall right, it's infact all relative paths based on where the
compiler driver and proper is installed.  But allows to be overriden based
on compilation flags such as changing architecture.


 Alternatively, what do I have to change to choose my own location for






gdc to install its imports to and have it automatically use that as an
import path? I have seen

 Can't you just use --prefix when configuring?



 That deals with the prefix, but not the suffix.



 Ore use -I or the D_IMPORT_PATH environment variable?



 I'm packaging GDC, so those aren't good solutions here.


Just packaging GDC? Or do you plan to have third party development
libraries packaged too?

The defaults install everything into a version and multiarch specific
directory.  This allows having any arbitrary number of versions installed,
both native and cross compilations.  You probably want a very good reason
to change that.


 Anyway, the code you'll have to look at is here:




https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/d-incpath.cc

 Look at add_import_paths, called from d_init in d-lang.cc



 https://github.com/Dicebot/Arch-PKGBUILDs/blob/master/gdc/folders.diff






and followed that example, but of course changing configure.ac is a pain
because then you have to have exactly the right version of autoconf to
update configure. Also, I couldn't find the relevant lines to change in
gcc/d/Make-lang.in

 That code was refactored and the patch isn't valid anymore:




https://github.com/D-Programming-GDC/GDC/commit/5ea9c2a61d548d2edb65401cbb88c88b123aef53?w=0

 So the /d suffix is hard-coded in to gdc? Can I just patch it to be


whatever I want before compiling gdc or are there other places that would
also need changing?

 Currently I tried changing gdc_include_dir in the generated configure,






which gets everything installed in the right place, but gdc doesn't import
it (and doesn't show any import paths in the error message)

 Which error message exactly? Does DMD print the import path for these




errors?

 I don't have the exact ones to hand right now, but it's the usual


complaint about not being able to find object.d. When an import is missing,
the compiler normally spits out a list of the include paths (same as in
dmd, checked also with gdc on archlinux), but in this case it didn't print
any.

Probably because none of the directories the compiler looked for exists.



 Oct 14 2015



  parent reply John Colvin <john.loughran.colvin gmail.com>  writes:


On Thursday, 15 October 2015 at 06:43:46 UTC, Iain Buclaw wrote:

 Just packaging GDC? Or do you plan to have third party 
 development libraries packaged too?


just GDC for now, no plans for libs at the moment.


 The defaults install everything into a version and multiarch 
 specific directory.  This allows having any arbitrary number of 
 versions installed, both native and cross compilations.  You 
 probably want a very good reason to change that.


For me everything ends up in normal bin, lib, include, libexec 
and share directories under whatever I put as prefix, which 
`configure --help` informs me defaults to /usr/local. I only get 
the version/multiarch stuff as a prefix in the names of copies of 
the main executables in bin.

To be honest, this is all such a pain I think i'll just let gdc 
do whatever it wants to in a separate directory and then symlink 
the bits that the user actually needs access to using whatever 
directories and naming I want.



 Oct 15 2015



  parent  "Iain Buclaw via D.gnu" <d.gnu puremagic.com>  writes:


On 15 October 2015 at 11:16, John Colvin via D.gnu <d.gnu puremagic.com>
wrote:


 On Thursday, 15 October 2015 at 06:43:46 UTC, Iain Buclaw wrote:


 Just packaging GDC? Or do you plan to have third party development
 libraries packaged too?


 just GDC for now, no plans for libs at the moment.

 The defaults install everything into a version and multiarch specific

 directory.  This allows having any arbitrary number of versions installed,
 both native and cross compilations.  You probably want a very good reason
 to change that.


 For me everything ends up in normal bin, lib, include, libexec and share
 directories under whatever I put as prefix, which `configure --help`
 informs me defaults to /usr/local. I only get the version/multiarch stuff
 as a prefix in the names of copies of the main executables in bin.

 To be honest, this is all such a pain I think i'll just let gdc do
 whatever it wants to in a separate directory and then symlink the bits that
 the user actually needs access to using whatever directories and naming I
 want.



Optionally, you can see how gcc is configured  (gcc --verbose) and use the
same "Configured with" options, this is so all sysroot/prefix/etc... match
up.



 Oct 15 2015