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
↑↓←→ 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
↑ ↓←→ 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
↑ ↓ ←→ 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?
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
↑ ↓ ←→ 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?
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
↑ ↓ ← → James Mansion <james mansionfamily.plus.com> writes:
I don't know what the state of LLVM is, or how ready it is, but
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
↑↓←→ 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
↑ ↓ ← → 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.
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
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
Jun 25 2008
↑ ↓← → 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
↑ ↓ ←→ James Mansion <james mansionfamily.plus.com> writes:
But I really don't see a reason why there is a need for two
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.
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
of the linkers is Open Source (and written in C).
Christof
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
↑ ↓ ← → 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.
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
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.
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
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next