-libpath?
Jonathan Marler
johnnymarler at gmail.com
Wed Feb 21 23:01:44 UTC 2018
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.
More information about the Digitalmars-d
mailing list