www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there a way to use x86 and x86_mscoff with dub simultaneously.

reply ciechowoj <keepitsimplesirius gmail.com> writes:
Currently dub reports following message when the -m32mscoff flag 
is specified in dub.json.


```
-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to 
specify the target architecture, e.g. 'dub build --arch=x86_64'
```

The problem is after the change the user is unable to build the 
project just with `dub build` (they need to specify the arch 
explicitly).

Is there a way to avoid the requirement for specifying the 
architecture explicitly or at least provide a meaningful message 
to the user that they should use `--arch=x86_mscoff` ?

Or a way to force dub to use VS linker instead of OPTLINK for x86 
case?
Or a way to override the default architecture?
Jul 25
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
 Currently dub reports following message when the -m32mscoff 
 flag is specified in dub.json.


 ```
 -m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to 
 specify the target architecture, e.g. 'dub build --arch=x86_64'
 architecture explicitly or at least provide a meaningful 
 message to the user that they should use `--arch=x86_mscoff` ?
What's wrong with the current error message? Doesn't it do that?
 Or a way to force dub to use VS linker instead of OPTLINK for 
 x86 case?
 Or a way to override the default architecture?
That's precisely what --arch (or simply -a) is for. But you can avoid passing it explicitly by setting the $DUB_ARCH environment variable (as per the dub documentation).
Jul 25
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-07-25 17:18, Mike Parker wrote:

 That's precisely what --arch (or simply -a) is for. But you can avoid 
 passing it explicitly by setting the $DUB_ARCH environment variable (as 
 per the dub documentation).
The use case is for DStep which requires to link with the Microsoft tool chain since the Clang libraries are only available in the COFF format. To make it as convenient as possible it would be nice to be able to specify in the dub.json without getting warnings. -- /Jacob Carlborg
Jul 25
prev sibling parent reply ciechowoj <keepitsimplesirius gmail.com> writes:
As Jacob Carlborg said it's for the dstep.

On Tuesday, 25 July 2017 at 15:18:04 UTC, Mike Parker wrote:
 On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
 What's wrong with the current error message? Doesn't it do that?
Nope, this message looks like intended for the library author rather than for a library user. What I want is a message that signals that the compilation isn't possible with the default x86 arch and the user has to use x86_mscoff arch.
 That's precisely what --arch (or simply -a) is for. But you can 
 avoid passing it explicitly by setting the $DUB_ARCH 
 environment variable (as per the dub documentation).
To disable the warning I mentioned in the first post I needed to remove the `-m32mscoff` flag. Now the library can be compiled only with explicit specification of the architecture. However the default arch is what the library's end user will select most likely. And then they will receive unhelpful message about OPTLINK being unable to parse the VS linker command line. Ideally I would like to be able to suppress m32mscoff warning and build for x86_mscoff by default (or amd64). Setting $DUB_ARCH is unacceptable as well.
Jul 25
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 25.07.2017 um 20:47 schrieb ciechowoj:
 As Jacob Carlborg said it's for the dstep.

 On Tuesday, 25 July 2017 at 15:18:04 UTC, Mike Parker wrote:
 On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
 What's wrong with the current error message? Doesn't it do that?
Nope, this message looks like intended for the library author rather than for a library user. What I want is a message that signals that the compilation isn't possible with the default x86 arch and the user has to use x86_mscoff arch.
 That's precisely what --arch (or simply -a) is for. But you can avoid
 passing it explicitly by setting the $DUB_ARCH environment variable
 (as per the dub documentation).
To disable the warning I mentioned in the first post I needed to remove the `-m32mscoff` flag. Now the library can be compiled only with explicit specification of the architecture. However the default arch is what the library's end user will select most likely. And then they will receive unhelpful message about OPTLINK being unable to parse the VS linker command line. Ideally I would like to be able to suppress m32mscoff warning and build for x86_mscoff by default (or amd64). Setting $DUB_ARCH is unacceptable as well.
What you can do is to create a configuration that only works for x86_64: name "myproject" configuration "library" { platforms "x86_64" targetType "library" // ... } This will cause the configuration resolution to fail if the wrong architecture is selected. The downside is that I think the error message will not be very helpful currently (something like "could not resolve configuration for myproject"), but that should be fixable.
Jul 25
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-07-26 00:41, Sönke Ludwig wrote:

 What you can do is to create a configuration that only works for x86_64:
 
      name "myproject"
 
      configuration "library" {
          platforms "x86_64"
          targetType "library"
          // ...
      }
 
 This will cause the configuration resolution to fail if the wrong 
 architecture is selected. The downside is that I think the error message 
 will not be very helpful currently (something like "could not resolve 
 configuration for myproject"), but that should be fixable.
It needs to work for 32bit as well. But for 32bit it would only work with COFF. -- /Jacob Carlborg
Jul 25
prev sibling parent ciechowoj <keepitsimplesirius gmail.com> writes:
What do you think about adding an optional config value 
`defaultArch` to dub? It would be used when no arch is specified.

I could specify default arch as x86_64 and everything would be 
fine.
Jul 30