> I don't know what the state of LLVM is, or how ready it is, but
it still
> would be a major project to hook up with.

I think it will be a somewhat lesser task than building a 64 bit CG and your own linker and librarian and debugger interface though.

Apple are using it for real.

I'm really surprised you aren't monitoring it.

Still, its your prerogative.

James

Robert M. Münch wrote:
> On Mon, 23 Jun 2008 15:09:04 +0200, James Mansion <james@mansionfamily.plus.com> wrote:
> 
>> I had thought that there was some planned activity over linker etc
> 
> I'm mostly struggleing with DMC in that I have to compile all and everything to avoid linker problems. Not all libs can be converted to OMF format. So, the chain is:
> 
> - Alter build environment to use DMC
> 
> - Change source code to compile with DMC. Biggest problems is, that DMC doesn't look like MSVC to the pre-processor etc.
> 
> Walter, can't you just add some compiler options where I can specify which MSVC version DMC should fake?
> 
> Somethinglike -msvc=6|7|8
> 
> - Collect all necessary LIB files, try to convert them etc.
> 
> All this is quite hard work even for just replacing MSVC with DMC. If you compile open-source stuff from Unix it's even more work.
> 
> I recently setup MingW with MSYS and all kind of stuff (not an easy task as well) but now I can just compile linux projects with autoconf / configure etc. Much less hassel...
> 
> As much as I love DMC, as soon as you have to combine several projects for your app, it's not an easy task.

It is a time consuming process in most cases.

The usual recipe I use is:
   Does the software build with MSVC?
If so:
- generate the MSVC build environment if any.
- Translate the compiler switches to DMC equivalent ones.
- Grep the source tree to find the MSVC special sections (_MSC_VER).
Most project redefine _MSC_VER to somthing else, in that case use the replacment symbol. I use the -l option on grep to list the affected source files.
- Inspect the specials in each listed file and apply the __DMC__ (or replacment symbol) if neccessary.
In most cases a few modication are still needed to build the the project with DMC.


When the software dos not build with MSVC
   Does the software build with ANY compiler on win32?
use the same recipe but replace _MSC_VER for the 'other' one.
This usally implies much more work.


When the software does not build at all on win32
generate the build environment on the supported target for a supported compiler. Copy it over to win32. Build with DMC and grep for specific target dependecies and stub them out with replacment onces. When the whole thing builds with the stubs, inspect the stubs and "implement" or "interface" them to the Win32api.
This usually implies much much much more work.


Third party libs:
- Stay away a much as possible from converted coff2omf libs when they are not just simple standard conformant static C libs.
- prefer to generate import libs from provided dll's. Most of the time this works best (use DMC's coffimplib.exe)


Arjan

James Mansion wrote:
> So:
> 
> Is Boost fully working now?

No, there are quite some ICE's and other problems solved. It look more worse than in fact it is. Mainly because most boost libs use boost/test in their test suite.
DMC has troubles with boost/test and as a result all tests using boost/test fail. Although the lib might work perfectly well with DMC.

> 
> What about other 'reference' toolsets like Poco, wxWidgets, ACE,
> Qt?

Indeed wxWidgets is, there was some effort in porting ACE as well don't know the result/status.

> 
> I had thought that there was some planned activity over linker etc
> to make that a maintainable part of the chain and make way for 64
> bit?

Well the linker is going to be more and more a problem, it has some SMP problems, and is easily pushed over other limits with todays software demands.

64 bits support would be really nice and a Linux/BSD port even more!!

Arjan

On Wed, 25 Jun 2008 16:57:45 +0200, Arjan Knepper wrote:
> Well the linker is going to be more and more a problem, it has some SMP problems, and is easily pushed over other limits with todays software demands.

If you are concerned about the linker, why not get your hands dirty, get the Open Watcom linker and adapt it to make it work with Digital Mars? It's not that much work (left) - in fact I started it some years ago and almost got there (see http://cmeerw.org/prog/owtools/), but have shifted focus since then.

But I really don't see a reason why there is a need for two linkers when one of the linkers is Open Source (and written in C).


Christof

-- 
http://cmeerw.org                              sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

Christof Meerwald wrote:
> If you are concerned about the linker, why not get your hands dirty, get the
> Open Watcom linker and adapt it to make it work with Digital Mars? It's not
> that much work (left) - in fact I started it some years ago and almost got
> there (see http://cmeerw.org/prog/owtools/), but have shifted focus since
> then.
> 
> But I really don't see a reason why there is a need for two linkers when one
> of the linkers is Open Source (and written in C).

I really like how fast optlink is <g>.

On Tue, 24 Jun 2008 23:43:32 +0200, Walter Bright <newshound1@digitalmars.com> wrote:

>> - Change source code to compile with DMC. Biggest problems is, that DMC doesn't look like MSVC to the pre-processor etc.
>> Walter, can't you just add some compiler options where I can specify which MSVC version DMC should fake?
>
> DMC's preprocessor is 100% standard compliant. I just cannot work up the desire to emulate various VC bugs in it. For portable libraries, this shouldn't be a problem, because they shouldn't be relying on VC compiler bugs.

Hi Walter, by "look like MSVC" I don't mean to implement the same bugs. I meant that pre-define macros should be the same as MSVC. So that the source-code is pre-processed as if MSVC would be used. If this would lead to pre-processing errors because MSVC has bugs and DMC not, I think it's perfectly OK to change the source and report those changes back to the project.

What I do at the moment as well. My sugestion is directed to avoid that I have to add "|| defined __DMC__" at several places.

> I understand. I've tried in the past to make DMC match other compilers' buggy behavior, but it's a losing game for me as the bugs constantly shift. What has worked better is making it standard compliant.

Again, I don't DMC should mimic bugs. A lot would be gained if it just uses the same pre-defined macros.

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de

On Wed, 25 Jun 2008 16:22:34 +0200, Arjan Knepper <arjan@ask.me.to> wrote:

> It is a time consuming process in most cases.
>
> The usual recipe I use is:
>     Does the software build with MSVC?
> ...

Hi Arjan, thanks for showing us which process you use to get things compiled with DMC.

> Third party libs:
> - Stay away a much as possible from converted coff2omf libs when they are not just simple standard conformant static C libs.

Yes, that's my experience as well. I just recently found out that the MingW linker can handle mostly everything available. I haven tested with OMF libs yet. But maybe it would be a good idea to use this linker than.

@Walter, is it really that hard to replace the linker? I know that Optlink is fast, has a lot of assembler and is a nice linker but it's a stranger in the world. Maybe using a different linker is an option. Does D produce OMF files as well?

I still think that C/C++ compilers are needed for several years and it would help.

> - prefer to generate import libs from provided dll's. Most of the time this works best (use DMC's coffimplib.exe)

Yes, but I'm not a fan of DLLs at all. That's why I try to compile the sources, create static libs and link everything together. It makes live for the user much more convinient. One EXE that's it. When I use scripting languages, I pack all the stuff into one DLL that can be called.

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de

On Tue, 24 Jun 2008 23:40:13 +0200, Walter Bright <newshound1@digitalmars.com> wrote:

> Not necessarily. Most Boost developers spent a very large amount of time getting their libraries to work around the various compiler vagaries - time the vendor didn't invest.

Has anyone any experience with the Comeau compiler stuff? Maybe this would help.

http://www.comeaucomputing.com

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de

On Wed, 25 Jun 2008 23:33:39 +0200, Walter Bright <newshound1@digitalmars.com> wrote:

> I really like how fast optlink is <g>.

I too, but it's like driving a Porsche with 500 HP but only driving in a circle. You are fast but won't move. If the rest is driving somewhere else the 500 HP don't help.

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de

> But I really don't see a reason why there is a need for two
linkers when one
> of the linkers is Open Source (and written in C).
> Christof

Have you looked at uldar?

(See http://www.ultimatepp.org/www$uppweb$download$en-us.html)

I'm not sure that I find the speed of optlink to be a big deal in the grand scheme of things, but then I tend to produce lots of DLLs. It shouldn't be necessary to use assembler to get good linking performance on a modern system - a decent IO strategy and good algorithms will be fine.