On Friday, 12 October 2012 at 07:39:15 UTC, Manu wrote:
> On 12 October 2012 09:51, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2012-10-12 07:46, Paulo Pinto wrote:
>>
>>  This already exists, it is called NuGet.
>>>
>>
>> Again, it's not cross-platform. How well does it work with D, at all?
>
>
> That's strictly for Microsoft .NET packages isn't it?

At the moment yes, but there are plans to expose C++ libraries as well.

But you can also make use of chocolatey already, to make other types of libraries available.

--
Paulo

On Friday, 12 October 2012 at 06:51:19 UTC, Jacob Carlborg wrote:
> On 2012-10-12 07:46, Paulo Pinto wrote:
>
>> This already exists, it is called NuGet.
>
> Again, it's not cross-platform. How well does it work with D, at all?

Fare enough, I got the feeling that the conversation had turned into Windows specific stuff.

--
Paulo

On Thursday, 11 October 2012 at 22:50:38 UTC, Iain Buclaw wrote:
> So the object that interprets pragma(lib) is able to communicate with
> the object that handles what flags to pass to the linker. :-)

Yes, and pragma(lib) is already supported in LDC.

> This is not possible with gdc, as the driver that handles the calling
> of ld (gdc) does not / cannot communicate with the compiler component
> (cc1d).

Can't you just do something along the lines of having "gdc test.d" internally calling "cc1d -o … --write-additional-libraries-to-this-file=/tmp/unique.library.deps.file.or.pipe" and read from that file/pipe later when linking? Or is this forbidden by some GCC rules?

David

On 12 October 2012 10:47, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 11 October 2012 at 22:50:38 UTC, Iain Buclaw wrote:
>>
>> So the object that interprets pragma(lib) is able to communicate with
>> the object that handles what flags to pass to the linker. :-)
>
>
> Yes, and pragma(lib) is already supported in LDC.
>
>
>> This is not possible with gdc, as the driver that handles the calling
>> of ld (gdc) does not / cannot communicate with the compiler component
>> (cc1d).
>
>
> Can't you just do something along the lines of having "gdc test.d"
> internally calling "cc1d -o …
> --write-additional-libraries-to-this-file=/tmp/unique.library.deps.file.or.pipe"
> and read from that file/pipe later when linking? Or is this forbidden by
> some GCC rules?
>
> David

Don't think that would be a simple thing to do in the current infrastructure.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 10 October 2012 at 11:39:29 UTC, Iain Buclaw wrote:
> NB: GCC has no such equivalent

hmm... really? Tough it seems like ld parses .drectve section:
http://pastebin.com/mc63b1b1
http://www.ibiblio.org/gferg/ldp/man/man1/dlltool.1.html
And syntax used sort of resembles that of gnu tools.

.drective looks to be for functions, not libraries.

----
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 12 Oct 2012 17:31, "Kagamin" <spam@here.lot> wrote:
>
> On Wednesday, 10 October 2012 at 11:39:29 UTC, Iain Buclaw wrote:
>>
>> NB: GCC has no such equivalent
>
>
> hmm... really? Tough it seems like ld parses .drectve section:
> http://pastebin.com/mc63b1b1
> http://www.ibiblio.org/gferg/ldp/man/man1/dlltool.1.html
> And syntax used sort of resembles that of gnu tools.

It looks to be for arbitrary linker commands.

ps I agree that building should be handled by a build system and/or a build script.

From COFF spec:
------
The .drectve Section (Object Only)
A section is a “directive” section if it has the IMAGE_SCN_LNK_INFO flag set in the section header. By convention, such a section also has the name .drectve. The linker removes a .drectve section after processing the information, so the section does not appear in the image file being linked. Note that a section marked with IMAGE_SCN_LNK_INFO that is not named .drectve is ignored and discarded by the linker.

A .drectve section consists of a string of ASCII text. This string is a series of linker options (each option containing hyphen, option name, and any appropriate attribute) separated by spaces. The .drectve section must not have relocations or line numbers.

In a .drectve section, if the hyphen preceding an option is followed by a question mark (for example, “-?export”), and the option is not recognized as a valid directive, the linker must ignore it. This allows compilers and linkers to add new directives while maintaining compatibility with existing linkers, as long as the new directives are not required for the correct linking of the application. For example, if the directive enables a link-time optimization, it is acceptable if some linkers cannot recognize it.

On Thursday, 11 October 2012 at 07:10:57 UTC, Jacob Carlborg wrote:
> On 2012-10-11 04:54, Jesse Phillips wrote:
> I think it would be much better to work with packages and not individual libraries. You would just tell the build tool, compiler or whatever to use package "foo". Then the package manager figures out what libraries and dependencies it needs to link to and also the path to the import files.

Why can't I just tell the compile that I need library "foo," and the package manager can handle finding the package which provides that library?

Packages depend on other packages, code depends on other code. I don't think it makes sense for code to depend on a package. Granted, packages could provide code that is depended on...

On the note about flags... Most of them are external to the code, you could say they are the options of the package. However, for libraries, we have a separate program which can operate without the source code, thus the historical reason code dependencies are not stated in the code. Why should we have 'import?' Can't we just tell the compiler the files it will need for its symbols separately, I don't know... maybe we could add a flag to specify them so it would feel strange to have them in the source code too. (Sorry couldn't pass it up)

As for the version number, you are right, I should know. But much of the code I write/use doesn't make release. This is where a handy and easy to use package manager comes in. Releases become simpler, there can be verified and tested versions of the depended libraries. But even with a tested version, that doesn't mean it will fail with older or newer versions of the package.

Linux creates symbolic links to its shared libraries to provide an unversioned link. And while all the packages know which version that is, third part applications do not. Yes, this arbitrary guessing game has its problems, but so does the strict version requirements. I've had to create symbolic links to a newer library to pretend I had an older version (as digging up such a version becomes hard when the package manager becomes worthless).

Anyway, I look forward to a good packaging system for D. But stating the dependency in that doing the depending does make sense. However I've realized that the dependency on a library only makes sense for header files, and header files only make sense when interfacing with C. Dependency on D code and libraries all come stated from the 'import' statement.

On 2012-10-12 23:43, Jesse Phillips wrote:

> Why can't I just tell the compile that I need library "foo," and the
> package manager can handle finding the package which provides that library?

Because package "foo" can contain several libraries. You also don't want to bother with the libraries "foo" depends on.

Say you have a project where you want to use Derelict. I much rather just say:

package derelict

Then some thing like this:

library libDerelictGL.a
library libDerelictUtil.a

> Packages depend on other packages, code depends on other code. I don't
> think it makes sense for code to depend on a package. Granted, packages
> could provide code that is depended on...

I don't understand why.

> On the note about flags... Most of them are external to the code, you
> could say they are the options of the package. However, for libraries,
> we have a separate program which can operate without the source code,
> thus the historical reason code dependencies are not stated in the code.
> Why should we have 'import?' Can't we just tell the compiler the files
> it will need for its symbols separately, I don't know... maybe we could
> add a flag to specify them so it would feel strange to have them in the
> source code too. (Sorry couldn't pass it up)

If you specify the path where the compiler should find import files in a source file, how should the compiler handle that?

* Have a special file that the compiler always reads first?

How is that any better than a build script?

* The compiler scans all files after these commands, add the import paths and then rescans the files?

This sounds very inefficient.

> As for the version number, you are right, I should know. But much of the
> code I write/use doesn't make release. This is where a handy and easy to
> use package manager comes in. Releases become simpler, there can be
> verified and tested versions of the depended libraries. But even with a
> tested version, that doesn't mean it will fail with older or newer
> versions of the package.

No, it does not.

> Linux creates symbolic links to its shared libraries to provide an
> unversioned link. And while all the packages know which version that is,
> third part applications do not. Yes, this arbitrary guessing game has
> its problems, but so does the strict version requirements. I've had to
> create symbolic links to a newer library to pretend I had an older
> version (as digging up such a version becomes hard when the package
> manager becomes worthless).

I think it's bad practice to depend on a library which you don't know the exact version.

But if you want, you don't need strict version requirements. RubyGems has this nice little feature of specifying versions:

gem "rails", "3.2.8" # specify exact version
gem "rails" # don't specify a version at all == latest version
gem "rails", "> 3.2.8" # any version newer than "3.2.8"

In these cases the digits in the version are interpreted as follows:

3 - Major
2 - Minor
8 - Build

Now, here's the interesting part:

gem "rails", "~> 3.2.8" # any version equal to 3.2.8 or a later build version

That is, "3.2.8" is ok, "3.2.15" is ok but "3.3.0" is not ok.

gem "rails", "~> 3.2" # any version equal to 3.2.0 or a later minor version

That is, "3.2.0" is ok, "3.2.8" is ok, "3.3.0" is ok but "4.0.0" is not ok.

> Anyway, I look forward to a good packaging system for D. But stating the
> dependency in that doing the depending does make sense. However I've
> realized that the dependency on a library only makes sense for header
> files, and header files only make sense when interfacing with C.
> Dependency on D code and libraries all come stated from the 'import'
> statement.

Ok, I really don't understand this last section.

-- 
/Jacob Carlborg