On 2012-10-11 18:00, Iain Buclaw wrote:

> Not what the LDC compiler does, the actual /usr/bin/ldc executable
> itself.  Is it in one pieces, or in pieces?  eg:  GDC is in two
> pieces, gdc and cc1d.

Why is that? I know that Clang does the same, I've always wonder why.

-- 
/Jacob Carlborg

On 2012-10-11 14:36, Walter Bright wrote:

> Are you saying that just to support pragma(lib), we should write a new
> linker?

No, not just because this feature alone. There are many other features that could be implemented with a smarter linker. There has been talk about this on the newsgroups several times. Better handling templates and overloaded functions, for example.

-- 
/Jacob Carlborg

On Thu, Oct 11, 2012 at 08:54:19PM +0200, Jacob Carlborg wrote:
> On 2012-10-11 16:23, H. S. Teoh wrote:
> 
> >Yeah, one of the poor design decisions of the early Redhat packaging system was to allow packages to depend on individual files, rather than packages. The result was a disastrous mess: some packages export different versions of the same file, and only a subset of them will work, leading to hair-tearing dependencies. Packages would step over each other's files, causing problems with each other and the rest of the system that depended on the same files, ad nauseum.
> 
> That sounds even worse, a terrible, terrible idea.
[...]

Yeah, it was one of the things that convinced me to *not* use Redhat. I saw a similar thing back in the Bad Old Days of Win98, Win2k, and their ilk, where installing a driver would sometimes prompt you something to the effect of "this driver needs to install a file that already exists; overwrite the file, delete it, or skip it?" None of those options should be anything the *user* has to decide, IMO. It essentially amounted to "flip a coin and pray the OS won't crash, and if you're *really* lucky the driver might actually work". Things like that convinced me *not* to use Windows. (I don't know if Windows still does that, as I don't use it anyore; but for everyone else's sake I would certainly hope it doesn't!)

Of course, IIRC Redhat has since fixed this broken design, but the horrible memory of it stuck. Debian, OTOH, has a depends-on-package policy, which results in a much saner system where a package can specify a dependency on other packages (with an entire package as a unit), optionally with a version constraint, and thus be ensured that it will get the correct versions of all related files. That was one of the things that convinced me to use Debian. :)


T

-- 
This is not a sentence.

On 11 October 2012 18:49, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 11 October 2012 at 16:01:09 UTC, Iain Buclaw wrote:
>>
>> On 11 October 2012 16:29, David Nadlinger <see@klickverbot.at> wrote:
>>>
>>> On Thursday, 11 October 2012 at 15:18:07 UTC, Iain Buclaw wrote:
>>>>
>>>>
>>>> Does LDC only build one executable?
>>>
>>> […]
>>
>>
>> Not what the LDC compiler does, the actual /usr/bin/ldc executable itself.  Is it in one pieces, or in pieces?  eg:  GDC is in two pieces, gdc and cc1d.
>
>
> Ah, now I see what you mean. Yes, LDC consists of only one executable.
>
> David

So the object that interprets pragma(lib) is able to communicate with
the object that handles what flags to pass to the linker. :-)

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).


Regards,
-- 
Iain Buclaw

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

On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote:
> Okay, so I'll stop being a dick for a minute, I'm actually curious to know
> how you imagine it working with a tool like VisualStudio.
> It sounds like you're not just talking about a tool to fetch libs and
> dependencies, but also perform the build? And the dependencies are detailed
> in the build script?
> An inflexible build system like Visual Studio doesn't really handle that
> very well.
>

In an ideal world, your VS plugin would support Packages in the Add References dialog. Just like you could, in theory, add a project as a reference, you would add a package. Then, upon build, the plugin would call the package manager and get the libraries / imports required for it, appending the options to the compilre for your own build. This is something that wouldn't be particularly difficult to make a plugin for given an existing package manager. Mono-Develop would perform in the same way I'd imagine.

On Thursday, 11 October 2012 at 23:03:45 UTC, Kapps wrote:
> On Thursday, 11 October 2012 at 11:46:39 UTC, Manu wrote:
>> Okay, so I'll stop being a dick for a minute, I'm actually curious to know
>> how you imagine it working with a tool like VisualStudio.
>> It sounds like you're not just talking about a tool to fetch libs and
>> dependencies, but also perform the build? And the dependencies are detailed
>> in the build script?
>> An inflexible build system like Visual Studio doesn't really handle that
>> very well.
>>
>
> In an ideal world, your VS plugin would support Packages in the Add References dialog. Just like you could, in theory, add a project as a reference, you would add a package. Then, upon build, the plugin would call the package manager and get the libraries / imports required for it, appending the options to the compilre for your own build. This is something that wouldn't be particularly difficult to make a plugin for given an existing package manager. Mono-Develop would perform in the same way I'd imagine.

This already exists, it is called NuGet.

Besides, Visual Studio projects are actually MSBuild scripts, for me that is quite flexible.

--
Paulo

On 2012-10-12 01:03, Kapps wrote:

> In an ideal world, your VS plugin would support Packages in the Add
> References dialog. Just like you could, in theory, add a project as a
> reference, you would add a package. Then, upon build, the plugin would
> call the package manager and get the libraries / imports required for
> it, appending the options to the compilre for your own build. This is
> something that wouldn't be particularly difficult to make a plugin for
> given an existing package manager. Mono-Develop would perform in the
> same way I'd imagine.

Exactly, that's how I'm thinking.

-- 
/Jacob Carlborg

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?

-- 
/Jacob Carlborg

On 2012-10-11 21:45, H. S. Teoh wrote:

> Yeah, it was one of the things that convinced me to *not* use Redhat. I
> saw a similar thing back in the Bad Old Days of Win98, Win2k, and their
> ilk, where installing a driver would sometimes prompt you something to
> the effect of "this driver needs to install a file that already exists;
> overwrite the file, delete it, or skip it?" None of those options should
> be anything the *user* has to decide, IMO. It essentially amounted to
> "flip a coin and pray the OS won't crash, and if you're *really* lucky
> the driver might actually work". Things like that convinced me *not* to
> use Windows. (I don't know if Windows still does that, as I don't use it
> anyore; but for everyone else's sake I would certainly hope it doesn't!)

Haha.

> Of course, IIRC Redhat has since fixed this broken design, but the
> horrible memory of it stuck. Debian, OTOH, has a depends-on-package
> policy, which results in a much saner system where a package can specify
> a dependency on other packages (with an entire package as a unit),
> optionally with a version constraint, and thus be ensured that it will
> get the correct versions of all related files. That was one of the
> things that convinced me to use Debian. :)

That's how it should work. The smallest unit should be a package.

-- 
/Jacob Carlborg

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?