Dmd's setup construction is a bit weird and has some difficult issue tracking.

How about if dmd supported, if it already doesn't, some ways to help the user check the configuration of dmd. It would be quick and easy to implement.

e.g.,

dmd -showinfo

Target Arch: x86
Libraries: C:\Mylib;C:\Another\Lib\Somewhere
Modules: C:\MyModules;
Version: 2.062
etc...

This way, issues between 64 and 32 paths can easily be seen... figuring out exactly what sc.ini is doing is easier, etc...

We know it is accurate because it would come from the compiler itself. No guessing.

Probably a dmd app could be created that does this instead? Basically I've ran into issues before setting up D because of path issues(again, the sc.ini file is pretty crappy... littered with duplicate symbols and different paths with "hacks" for different compilers and all that(it's just not sain)). It tends to make me hesitant dealing with dmd in some cases. Something that should take a min to do can take hours trying to track down some weird issue simply because of a typo... and there's no way to know exactly what the compiler is "seeing"... I really hope something like this already exists.

On Monday, 11 January 2016 at 01:22:28 UTC, Jason Jeffory wrote:
> Dmd's setup construction is a bit weird and has some difficult issue tracking.
>
> How about if dmd supported, if it already doesn't, some ways to help the user check the configuration of dmd. It would be quick and easy to implement.
>
> e.g.,
>
> dmd -showinfo
>
> Target Arch: x86
> Libraries: C:\Mylib;C:\Another\Lib\Somewhere
> Modules: C:\MyModules;
> Version: 2.062
> etc...
>
> This way, issues between 64 and 32 paths can easily be seen... figuring out exactly what sc.ini is doing is easier, etc...
>
> We know it is accurate because it would come from the compiler itself. No guessing.
>
> Probably a dmd app could be created that does this instead? Basically I've ran into issues before setting up D because of path issues(again, the sc.ini file is pretty crappy... littered with duplicate symbols and different paths with "hacks" for different compilers and all that(it's just not sain)). It tends to make me hesitant dealing with dmd in some cases. Something that should take a min to do can take hours trying to track down some weird issue simply because of a typo... and there's no way to know exactly what the compiler is "seeing"... I really hope something like this already exists.

Also, any linked in libraries could report there format and such. I've had problems figuring out certain coeff libs issues and all that. Knowing exactly what's going on is a good thing, right?!?!?

On Monday, 11 January 2016 at 01:24:44 UTC, Jason Jeffory wrote:
> On Monday, 11 January 2016 at 01:22:28 UTC, Jason Jeffory wrote:
>> Dmd's setup construction is a bit weird and has some difficult issue tracking.
>>
>> How about if dmd supported, if it already doesn't, some ways to help the user check the configuration of dmd. It would be quick and easy to implement.
>>
>> e.g.,
>>
>> dmd -showinfo
>>
>> Target Arch: x86
>> Libraries: C:\Mylib;C:\Another\Lib\Somewhere
>> Modules: C:\MyModules;
>> Version: 2.062
>> etc...
>>
>> This way, issues between 64 and 32 paths can easily be seen... figuring out exactly what sc.ini is doing is easier, etc...
>>
>> We know it is accurate because it would come from the compiler itself. No guessing.
>>
>> Probably a dmd app could be created that does this instead? Basically I've ran into issues before setting up D because of path issues(again, the sc.ini file is pretty crappy... littered with duplicate symbols and different paths with "hacks" for different compilers and all that(it's just not sain)). It tends to make me hesitant dealing with dmd in some cases. Something that should take a min to do can take hours trying to track down some weird issue simply because of a typo... and there's no way to know exactly what the compiler is "seeing"... I really hope something like this already exists.
>
> Also, any linked in libraries could report there format and such. I've had problems figuring out certain coeff libs issues and all that. Knowing exactly what's going on is a good thing, right?!?!?

and how does one link in compiled static libraries into a dub project?

I tried adding stuff like

"lflags" : ["+C:\\MyLibs\\"],

with the .lib file in it, but that doesn't work. (I'd expect to have to supply the file name somewhere, at least)

Thanks.

On 2016-01-11 01:47:54 +0000, Jason Jeffory said:

> and how does one link in compiled static libraries into a dub project?
> 
> I tried adding stuff like
> 
> "lflags" : ["+C:\\MyLibs\\"],
> 
> with the .lib file in it, but that doesn't work. (I'd expect to have to supply the file name somewhere, at least)
> 
> Thanks.

I agree with all your other points. Telling explicit what's going on would help a lot in daily business. Not only for D but all compiler stuff. But it seems to be tradition to not do this.

Anyway, regarding the static libs. I used this on a Win64 project and it works:

       "lflags" : [
         "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib",
         "D:\\develop\\cairo\\libpng\\libpng.lib",
         "gdi32.lib"
       ],


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 11 January 2016 at 05:46:11 UTC, Robert M. Münch wrote:
> On 2016-01-11 01:47:54 +0000, Jason Jeffory said:
>
>> and how does one link in compiled static libraries into a dub project?
>> 
>> I tried adding stuff like
>> 
>> "lflags" : ["+C:\\MyLibs\\"],
>> 
>> with the .lib file in it, but that doesn't work. (I'd expect to have to supply the file name somewhere, at least)
>> 
>> Thanks.
>
> I agree with all your other points. Telling explicit what's going on would help a lot in daily business. Not only for D but all compiler stuff. But it seems to be tradition to not do this.
>
> Anyway, regarding the static libs. I used this on a Win64 project and it works:
>
>        "lflags" : [
>          "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib",
>          "D:\\develop\\cairo\\libpng\\libpng.lib",
>          "gdi32.lib"
>        ],

Thanks, that works but

1. *not a valid lib file* (glfw3.lib) ;/ Ok,
2. What about 64? Does one have to maintain two branches for that?

I don't understand why the trend is not to be verbose but to hide details ;/ It's simply the wrong way.


1. Trying windows link instead, remember having problems like this in the past with optlink.

"LINK : fatal error LNK1104: cannot open file '_CMDLINE'"

;/

tried converting with coffimplib, not an import library. Another rabbit hole to go down ;/ (Why do programmers make programmers life hell?)

After trying other various things that didn't work, I'm done for today... too frustrating. Hopefully I'll come back tomorrow with a nice surprise.

On Monday, 11 January 2016 at 16:27:54 UTC, Jason Jeffory wrote:

>>
>> Anyway, regarding the static libs. I used this on a Win64 project and it works:
>>
>>        "lflags" : [
>>          "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib",
>>          "D:\\develop\\cairo\\libpng\\libpng.lib",
>>          "gdi32.lib"
>>        ],
>
> Thanks, that works but

lflags is probably not the best way to do it. The "libs" field is better. This will guarantee that the library is passed in a compiler-appropriate manner across platforms. lflags is compiler-specific.

> 1. *not a valid lib file* (glfw3.lib) ;/ Ok,

It's likely a COFF vs OMF issue.

> 2. What about 64? Does one have to maintain two branches for that?

No. You might keep the libraries in separate directories or use a naming convention (like appending -32 or -64 on the library names) to distinguish them. Using DUB, you could then add something like the following:

"libs-windows-dmd-x86": ["myWinLib-32"],
"libs-windows-dmd-x86_64": ["myWinLib-64"]

Drop the "windows" bit for cross-platform stuff. Of course, this is dependent upon you passing -ax86_64 to DUB when you want to compile for 64-bit


>
> 1. Trying windows link instead, remember having problems like this in the past with optlink.
>
> "LINK : fatal error LNK1104: cannot open file '_CMDLINE'"
>
> ;/
>
> tried converting with coffimplib, not an import library. Another rabbit hole to go down ;/ (Why do programmers make programmers life hell?)

coffimplib [1] is for converting import libraries, not static libraries. You can also use implib (part of the basic utilities package [2]) to generate an import library if you have a DLL. You should use coff2omf [3] to convert static libraries and object files.

You can avoid all of these headaches by using dynamic bindings like those at DerelictOrg [4] if they are available for the libraries you use. Then the compile-time dependency on the C library goes away and all you need is the DLL at runtime.

[1] http://www.digitalmars.com/ctg/coffimplib.html
[2] http://www.digitalmars.com/download/freecompiler.html
[3] http://www.digitalmars.com/ctg/coff2omf.html
[4] https://github.com/DerelictOrg

On 2016-01-12 04:15:36 +0000, Mike Parker said:

> You can avoid all of these headaches by using dynamic bindings like those at DerelictOrg [4] if they are available for the libraries you use. Then the compile-time dependency on the C library goes away and all you need is the DLL at runtime.

I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days.

How simple would it be to just have one self-contained executable?

And all the Docker hype is doing / simulating this with a sledgehammer.

I prefer to link everything static, and it saved us and our clients hours of headache. Drivespace is no limiting factor anymore, but time and customer satisfaction is always.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On 2016-01-11 02:22, Jason Jeffory wrote:
> Dmd's setup construction is a bit weird and has some difficult issue
> tracking.
>
> How about if dmd supported, if it already doesn't, some ways to help the
> user check the configuration of dmd. It would be quick and easy to
> implement.
>
> e.g.,
>
> dmd -showinfo
>
> Target Arch: x86
> Libraries: C:\Mylib;C:\Another\Lib\Somewhere
> Modules: C:\MyModules;
> Version: 2.062
> etc...

You can get some more information by compiling with the "-v" flag. In the top it will print the config used, i.e. the path to sc.ini the compiler found. At the bottom it will print the command it uses for linking.

-- 
/Jacob Carlborg

On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch wrote:

> I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days.

I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell.

On Tuesday, 12 January 2016 at 12:32:11 UTC, Mike Parker wrote:
> On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch wrote:
>
>> I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days.
>
> I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell.

To clarify, static bindings can be used when linking both statically and dynamically. Dynamic bindings have no link-time dependency at all and are used to load a dynamic library manually at runtime.