What do people think of adding an argument to DMD to add library search paths?  Currently the only way I know how to do this would be via linker-specific flags, i.e.

GCC: -L-L/usr/lib
MSVC: -L-libpath:C:\mylibs
OPTLINK: -L+C:\mylibs\

NOTE: the optlink version only works if no .def file is specified.  If you have a .def file, then you can't add any library search paths :)

If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using.  I'd expect the argument to be something like:

-libpath=<some-path>

The disadvantage is it would be another command line option added to DMD.  If there is general agreement that this is a desirable feature, I'll go ahead and implement it.

On Tuesday, 6 February 2018 at 17:49:33 UTC, Jonathan Marler wrote:
> What do people think of adding an argument to DMD to add library search paths?  Currently the only way I know how to do this would be via linker-specific flags, i.e.
>
> GCC: -L-L/usr/lib
> MSVC: -L-libpath:C:\mylibs
> OPTLINK: -L+C:\mylibs\
>
> NOTE: the optlink version only works if no .def file is specified.  If you have a .def file, then you can't add any library search paths :)
>
> If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using.  I'd expect the argument to be something like:
>
> -libpath=<some-path>
>
> The disadvantage is it would be another command line option added to DMD.  If there is general agreement that this is a desirable feature, I'll go ahead and implement it.

no one responded to this, but I thought I would bump this to the front page to double check if there is any interest in this feature.

On Tuesday, 6 February 2018 at 17:49:33 UTC, Jonathan Marler wrote:
> What do people think of adding an argument to DMD to add library search paths?  Currently the only way I know how to do this would be via linker-specific flags, i.e.
>
> GCC: -L-L/usr/lib
> MSVC: -L-libpath:C:\mylibs
> OPTLINK: -L+C:\mylibs\
>
> NOTE: the optlink version only works if no .def file is specified.  If you have a .def file, then you can't add any library search paths :)
>
> If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using.  I'd expect the argument to be something like:
>
> -libpath=<some-path>
>
> The disadvantage is it would be another command line option added to DMD.  If there is general agreement that this is a desirable feature, I'll go ahead and implement it.

Given the current state of things, and the issue described above, I think a linker/platform independent flag would be nice.

However, I'd much rather have the compiler just be a compiler and not have to worry about all the intricacies building.  IMO, the compiler should get out of the linking business altogether, and just generate object files.  A separate build tool could then call the compiler, linker, and whatever else to do builds.  But that ship has probably sailed.

Mike

On Wednesday, 21 February 2018 at 02:21:14 UTC, Jonathan Marler wrote:

>>
>> If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using.  I'd expect the argument to be something like:
>>
>> -libpath=<some-path>
>>
>> The disadvantage is it would be another command line option added to DMD.  If there is general agreement that this is a desirable feature, I'll go ahead and implement it.
>
> no one responded to this, but I thought I would bump this to the front page to double check if there is any interest in this feature.

There is a tool that lets you call GDC and use DMD command-line options (gdmd). If it doesn't already exist, what about a tool that allows you to call DMD using GDC options (which I think are the same as gcc/g++/clang/clang++)?

On Wednesday, 21 February 2018 at 10:23:08 UTC, Tony wrote:

>
> There is a tool that lets you call GDC and use DMD command-line options (gdmd). If it doesn't already exist, what about a tool that allows you to call DMD using GDC options (which I think are the same as gcc/g++/clang/clang++)?

I am mainly thinking about being about to do -L/the/path/to/abc and
-labc as is done for the Linux C/C++ compilers.

On Wednesday, 21 February 2018 at 04:07:38 UTC, Mike Franklin wrote:
> On Tuesday, 6 February 2018 at 17:49:33 UTC, Jonathan Marler wrote:
>> What do people think of adding an argument to DMD to add library search paths?  Currently the only way I know how to do this would be via linker-specific flags, i.e.
>>
>> GCC: -L-L/usr/lib
>> MSVC: -L-libpath:C:\mylibs
>> OPTLINK: -L+C:\mylibs\
>>
>> NOTE: the optlink version only works if no .def file is specified.  If you have a .def file, then you can't add any library search paths :)
>>
>> If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using.  I'd expect the argument to be something like:
>>
>> -libpath=<some-path>
>>
>> The disadvantage is it would be another command line option added to DMD.  If there is general agreement that this is a desirable feature, I'll go ahead and implement it.
>
> Given the current state of things, and the issue described above, I think a linker/platform independent flag would be nice.
>
> However, I'd much rather have the compiler just be a compiler and not have to worry about all the intricacies building.  IMO, the compiler should get out of the linking business altogether, and just generate object files.  A separate build tool could then call the compiler, linker, and whatever else to do builds.
>  But that ship has probably sailed.
>
> Mike

Interesting idea.  Actually I don't think it's too late for this.  It is too late for DMD to just be a compiler, but that doesn't mean the compiler can't be stripped out as a separate component that DMD interfaces with.  This would just make DMD a build tool/compiler/linker wrapper/etc that interfaces with underlying components that could be invoked independently as well.

In any case, DMD has evolved to make development more convenient, adding features in a monolithic fashion that could have otherwise been implemented using independent components as part of a suite of compiler software, not unlike LLVM.  However, this requires a lot more effort, creating interfaces between each component that then need to be well-defined and maintained...sometimes you just want to provide a feature without going through all the grunt work to make it robust.  I think this is a natural evolution of software. Most of it starts monolithic and components are pulled out as needed, and this can still be done for the D compiler.