October 11, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 |
October 11, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
October 11, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
October 11, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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'; |
October 11, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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.
|
October 12, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kapps | 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
|
October 12, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kapps | 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 |
October 12, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | 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 |
October 12, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 |
October 12, 2012 Re: #pragma comment (lib, ...) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| 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?
|
Copyright © 1999-2021 by the D Language Foundation