www.digitalmars.com         C & C++   DMDScript  

c++.beta - Bit quiet here

reply James Mansion <james mansionfamily.plus.com> writes:
Time to give up and move on?

Walter - is there any chance of a roadmap of any sort, even
without dates?
Jun 06 2008
next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Fri, 06 Jun 2008 14:44:37 +0200, James Mansion  
<james mansionfamily.plus.com> wrote:


 Time to give up and move on?

 Walter - is there any chance of a roadmap of any sort, even
 without dates?


Good point. I was wondering to if DMC is a dakota horse... Robert.
Jun 06 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:

 Time to give up and move on?
 
 Walter - is there any chance of a roadmap of any sort, even
 without dates?


I generally do things that follow the interests of the people that use it.
Jun 14 2008
next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Sat, 14 Jun 2008 23:21:58 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:


 I generally do things that follow the interests of the people that use  
 it.


That makes sense but I still think DMC is to valuable to leave it behind.

I posted some questions in c++.windows-32-bit but no responses... without  
a good community DMC users are lost. :-(

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de
Jun 15 2008
prev sibling parent reply James Mansion <james mansionfamily.plus.com> writes:
So:

Is Boost fully working now?

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

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?

There has certainly been some activity here (and in other fora)
relating to issues since the .51 reelase in January.

I don't quite know what to read into your reply!
Jun 23 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:

 So:
 
 Is Boost fully working now?


No, mainly because nobody has expended the effort to do so.


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


wxWidgets is


 
 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?


Going to have to do 64 bit sooner or later!


 
 There has certainly been some activity here (and in other fora)
 relating to issues since the .51 reelase in January.
 
 I don't quite know what to read into your reply!
Jun 23 2008
parent reply James Mansion <james mansionfamily.plus.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 James Mansion wrote:

 So:

 Is Boost fully working now?


 No, mainly because nobody has expended the effort to do so.


Doesn't that someone have to be you though?

We're somewhat dependent on you to do all teh fixes, and pretty
much all the triage, and without any activity here its impossible
to determine what's going on.  If, indeed, anything at all is
going on.


 Going to have to do 64 bit sooner or later!


Indeed.  Could hook up with LLVM maybe?

That project could benefit from greatly a non-gcc front end.  Do
you still have a material interest in using a proprietary back-end?

(Or indeed keeping the front end proprietary?  I have no idea how
you make your daily bread these days Walter - long time since we
met with John H and Dave Mansell in Woolwich!  But the BSD camp is
a compiler short of a toolset at the moment.)

James
Jun 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article

 James Mansion wrote:

 So:

 Is Boost fully working now?


 No, mainly because nobody has expended the effort to do so.


 
 Doesn't that someone have to be you though?


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. Trying to figure out why a Boost library 
fails usually requires a thorough understanding of that library - this 
is a big job for someone other than the library writer.

Once the problem is reduced to a small test case (nearly all reduce to 
10 lines or so), it can be posted to the DMC++ bugzilla.


 
 We're somewhat dependent on you to do all teh fixes, and pretty
 much all the triage, and without any activity here its impossible
 to determine what's going on.  If, indeed, anything at all is
 going on.
 

 Going to have to do 64 bit sooner or later!


 
 Indeed.  Could hook up with LLVM maybe?


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.


 
 That project could benefit from greatly a non-gcc front end.  Do
 you still have a material interest in using a proprietary back-end?
 
 (Or indeed keeping the front end proprietary?  I have no idea how
 you make your daily bread these days Walter - long time since we
 met with John H and Dave Mansell in Woolwich!  But the BSD camp is
 a compiler short of a toolset at the moment.)
 
 James
Jun 24 2008
next sibling parent James Mansion <james mansionfamily.plus.com> writes:
 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
Jun 25 2008
prev sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
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
Jun 27 2008
prev sibling next sibling parent reply =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
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.

-- 
Robert M. Münch
Management & IT Freelancer
http://www.robertmuench.de
Jun 24 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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?


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.


 
 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.


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.
Jun 24 2008
parent reply =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
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
Jun 27 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert M. Münch wrote:

 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, but I think it is just wrong for DMC to predefine _MSC_VER.
Jul 09 2008
prev sibling parent reply Arjan Knepper <arjan ask.me.to> writes:
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
Jun 25 2008
parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
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
Jun 27 2008
prev sibling parent reply Arjan Knepper <arjan ask.me.to> writes:
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
Jun 25 2008
parent reply Christof Meerwald <cmeerw cmeerw.org> writes:
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
Jun 25 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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>.
Jun 25 2008
parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
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
Jun 27 2008
prev sibling parent reply James Mansion <james mansionfamily.plus.com> writes:
 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.
Jun 27 2008
parent reply Christof Meerwald <NOSPAM-seeMySig cmeerw.org> writes:
On Fri, 27 Jun 2008 16:34:40 +0000 (UTC), James Mansion wrote:

 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?


Have you looked at it?

It says "uld COFF linker" which doesn't look like it would be of much use
for Digital Mars at the moment...


Christof

-- 
http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org
Jun 27 2008
parent James Mansion <james mansionfamily.plus.com> writes:
== Quote from Christof Meerwald (NOSPAM-seeMySig cmeerw.org)'s >
It says "uld COFF linker" which doesn't look like it would be of
much use

 for Digital Mars at the moment...
 Christof


Well, I *use* it, but fair cop I guess.

I'm assuming the current situation is untenable.


How far from usable is the OpenWatcom stuff?

I used to like the Watcom compiler and toolset but it got so
crufty that its been hard to justify any time at all.
Jun 30 2008