October 10, 2012
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
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
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
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
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
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
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
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
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
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