View mode: basic / threaded / horizontal-split · Log in · Help
October 10, 2012
Re: #pragma comment (lib, ...)
On 2012-10-10, 16:19, Walter Bright wrote:

> On 10/10/2012 4:26 AM, Manu wrote:
>> I think D's modules make this relationship even stronger, and it's a  
>> shame it's
>> not a standard part of D.
>
> Some object module formats do not have the ability to embed a library  
> reference in them. Elf (cough cough), Mach-O (wheeze)

ELF has .comment and .note sections. While they're not exactly intended
for the purpose, they seem to fit the bill?

It'd of course require a linker to know what to do with the data, but
it seems to me this would not interfere with other uses.

Note: The above comes from a 2-minute cursory read of the ELF standard,
and may thus contain errors. :p

-- 
Simen
October 10, 2012
Re: #pragma comment (lib, ...)
On 10 October 2012 16:45, Paulo Pinto <pjmlp@progtools.org> wrote:

>
> This only works if it is part of the language definition.
>
> In C and C++ case I am usually against it, because I favour portability
> over dependencies to a specific compiler vendor. Many years of writing
> multi-platform code do leave some scars.
>

Errr, what? This enhanced portability, that's the point.
I've spent my career writing more cross-platform code than most coders
would touch in their lives, and I give thanks for the platforms where it is
available.
It always leads to a vastly simplified path in the build scripts for those
platforms that support it, and typically produces more reliable and
less fickle results; ie, I never experience link problems with those
platforms.

Multi-platform code always has #ifdef guards around #pragma
comment(lib,)-ing the appropriate libs for the platform which the code is
being built for, and that is the whole point. The code its self selects the
libs it depends on by simply being compiled.


As for D, if this can be made part of the language then I see no big reason
> against it.
>

Well, DMD says it is ;) .. Question is, is it technically possible for
other compilers to support it?
October 10, 2012
Re: #pragma comment (lib, ...)
On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
> On 2012-10-10, 16:19, Walter Bright wrote:
>> Some object module formats do not have the ability to embed a library
>> reference in them. Elf (cough cough), Mach-O (wheeze)
>
> ELF has .comment and .note sections. While they're not exactly intended
> for the purpose, they seem to fit the bill?
>
> It'd of course require a linker to know what to do with the data, but
> it seems to me this would not interfere with other uses.

Exactly. Embedding it in a comment section accomplishes exactly nothing if the 
linker ignores it.
October 10, 2012
Re: #pragma comment (lib, ...)
On Wednesday, 10 October 2012 at 16:18:10 UTC, Manu wrote:
> On 10 October 2012 16:45, Paulo Pinto <pjmlp@progtools.org> 
> wrote:
>
>>
>> This only works if it is part of the language definition.
>>
>> In C and C++ case I am usually against it, because I favour 
>> portability
>> over dependencies to a specific compiler vendor. Many years of 
>> writing
>> multi-platform code do leave some scars.
>>
>
> Errr, what? This enhanced portability, that's the point.
> I've spent my career writing more cross-platform code than most 
> coders
> would touch in their lives, and I give thanks for the platforms 
> where it is
> available.
> It always leads to a vastly simplified path in the build 
> scripts for those
> platforms that support it, and typically produces more reliable 
> and
> less fickle results; ie, I never experience link problems with 
> those
> platforms.

I never state you did not. Actually since I know you do games 
development I suspect exactly that, that you are also aware of 
such issues.

>
> Multi-platform code always has #ifdef guards around #pragma
> comment(lib,)-ing the appropriate libs for the platform which 
> the code is
> being built for, and that is the whole point. The code its self 
> selects the
> libs it depends on by simply being compiled.

I tend to push for platform specific code to have their own set 
of files, thus
minimizing preprocessor usage.

I rather have a interface.h file with corresponding 
interface_osname.cpp files.

As I mentioned in other threads, when you work with cheap 
developers the code tends to be scary, so minimizing preprocessor 
usage is a GOOD thing.

>
>
> As for D, if this can be made part of the language then I see 
> no big reason
>> against it.
>>
>
> Well, DMD says it is ;) .. Question is, is it technically 
> possible for
> other compilers to support it?

You right here, I failed to look up the language definition.

--
Paulo
October 10, 2012
Re: #pragma comment (lib, ...)
On Wednesday, 10 October 2012 at 15:43:36 UTC, Simen Kjaeraas 
wrote:
> On 2012-10-10, 16:19, Walter Bright wrote:
>
>> On 10/10/2012 4:26 AM, Manu wrote:
>>> I think D's modules make this relationship even stronger, and 
>>> it's a shame it's
>>> not a standard part of D.
>>
>> Some object module formats do not have the ability to embed a 
>> library reference in them. Elf (cough cough), Mach-O (wheeze)
>
> ELF has .comment and .note sections. While they're not exactly 
> intended
> for the purpose, they seem to fit the bill?
>
> It'd of course require a linker to know what to do with the 
> data, but
> it seems to me this would not interfere with other uses.
>
> Note: The above comes from a 2-minute cursory read of the ELF 
> standard,
> and may thus contain errors. :p

This is how Go packages are compiled.

The compiler reads the libraries (.a, .o) for the symbol 
information of what a package exports.

--
Paulo
October 10, 2012
Re: #pragma comment (lib, ...)
On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:
> On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
> >On 2012-10-10, 16:19, Walter Bright wrote:
> >>Some object module formats do not have the ability to embed a library
> >>reference in them. Elf (cough cough), Mach-O (wheeze)
> >
> >ELF has .comment and .note sections. While they're not exactly intended
> >for the purpose, they seem to fit the bill?
> >
> >It'd of course require a linker to know what to do with the data, but
> >it seems to me this would not interfere with other uses.
> 
> Exactly. Embedding it in a comment section accomplishes exactly
> nothing if the linker ignores it.
[...]

I thought the point was that linkers that *did* understand it will do
the right thing, and linkers that don't will fall back to the
traditional way (require specifying libraries on the command-line).


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC
October 10, 2012
Re: #pragma comment (lib, ...)
On 2012-10-10 14:59, Manu wrote:

> None of those things actually embody the information about the
> relationship, nor can they. The source code does, and nothing else.
> Features that imply the dependency may (and often are) be disabled at
> compile time.
> I rather like that the compiler is able to put a note in the object file
> that it depends on a particular lib, because it does.
> I'm not sure how a package manager helps... What is a package manager? ;)
> I'd like to hear some reasons why that is a bad or undesirable thing, or
> is this just an opinion?

A package manager is a tool that downloads and installs libraries, 
application and tools, also known as packages. It also tracks and 
installs all the dependencies of a package automatically. RubyGems, 
CPAN, PEAR, npm are a couple of examples of package managers 
specifically made for a programming language.

This is my vision (simplified) of how build tool, package manager and 
the compiler work together.

# build script
package foo
package bar

files myapp/main.d

$ build myapp

The build tool "build" will read the build script and see that it has 
two dependencies: "foo" and "bar". The build tool will get information 
from the package manager about these packages. Information like the path 
to the import files/source/headers and the path to the library to link with.

The build tool will then simply invoke the compiler with the correct 
flags to be able to build and link with these libraries. The build tool 
will, of course, know the platform it runs on so it can call the 
compiler with different flags depending on the platform. On Posix it 
would probably link to "libfoo.a" where on Windows it would link to 
"foo.lib".

If I recall correctly, using pragma(lib) with dmd, you need to specify 
the extension for the library, ending up with code like this:

version (Posix)
    pragma(lib, "foo.lib");

else version (Windows)
    pragma(lib, "libfoo.a");

Which is just ridiculous. Sure you could change DMD to support for this. 
But what happens with dynamic libraries? .dll on Windows, .so on 
Linux/BSD and .dylib on Mac OS X. Then on Mac OS X there are various 
other types of dynamic libraries, like frameworks and bundles, with 
their own extension.

Another point is that I don't want to separate the build script. Compile 
and link flags in one file and then the libraries to link with in a 
different file? That's just stupid.

With the approach with the build tool and the package manager working 
together the build tool can also automatically specify the path to the 
import files. How would you do that in a source file? Either the 
compiler would always need to read a special file first. Or it would 
need to scan all files for a particular pragma to get the import paths. 
Then it would rescan the files again during the actual compilation.

This is a specification/description of a package manager I'm working on:

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

-- 
/Jacob Carlborg
October 10, 2012
Re: #pragma comment (lib, ...)
On 2012-10-10 16:26, Paulo Pinto wrote:

> Turbo Pascal was already doing this back in 1987.
>
> The Pascal family of languages always made me look down to C and C++
> toolchains as stone age technology that I have to endure when using
> those languages.
>
> This is actually one feature that I really like in JVM/.NET worlds, even
> in the native compiler versions that are available for them.

I think the Clang/LLVM tool chain is planing to do this, or already has.

-- 
/Jacob Carlborg
October 10, 2012
Re: #pragma comment (lib, ...)
On 10-Oct-12 22:54, H. S. Teoh wrote:
> On Wed, Oct 10, 2012 at 08:56:49AM -0700, Walter Bright wrote:
>> On 10/10/2012 8:19 AM, Simen Kjaeraas wrote:
>>> On 2012-10-10, 16:19, Walter Bright wrote:
>>>> Some object module formats do not have the ability to embed a library
>>>> reference in them. Elf (cough cough), Mach-O (wheeze)
>>>
>>> ELF has .comment and .note sections. While they're not exactly intended
>>> for the purpose, they seem to fit the bill?
>>>
>>> It'd of course require a linker to know what to do with the data, but
>>> it seems to me this would not interfere with other uses.
>>
>> Exactly. Embedding it in a comment section accomplishes exactly
>> nothing if the linker ignores it.
> [...]
>
> I thought the point was that linkers that *did* understand it will do
> the right thing, and linkers that don't will fall back to the
> traditional way (require specifying libraries on the command-line).
>

BTW making the smart linker driver should be relatively easy: just get 
the special section contents out of passed object files and turn that 
into a full blown set of flags for a dumb linker.

-- 
Dmitry Olshansky
October 10, 2012
Re: #pragma comment (lib, ...)
On 2012-10-10 17:00, Jesse Phillips wrote:

> Well, to comply with the standard it must at least ignore it.
>
> http://dlang.org/pragma.html
>
> I don't see this needing to be outside the source files. Actually I'd be
> happy if all that was supported was exporting that information, probably
> to the json. What bothers me with not having this information in the
> library is that each project I create will now need to copy and paste my
> lib dependencies, or the general need to remember what library is used
> by a given library.
>
> Marco,
>
> As for versions. I don't know what version of ole32.dll I'm using or how
> to find out, I don't really care either. But I guess it would be good to
> have the option though.

A package manager would be the solution for that.

-- 
/Jacob Carlborg
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home