I've reposted the original message. The indentations in the newsgroup was getting a little confusing.


On Fri, 12 Jan 2001 10:08:11 -0800, "Walter" <walter@digitalmars.com> wrote:
> 
> Damian Dixon wrote in message <1109_979295385@dilbert>...
> >> I appreciate all the work everyone here in the newsgroup is doing to
> produce
> >> workarounds for the template issues.
> >Is there anything the rest of us could do to help?
> 
> 
> Certainly, the work going on here to get a version of STL to work is great.
> 
I believe that I will not be able to get all of STLport working.

The STL part will need to be extended to include the hash containers and to support DOSX,

This is probably the area I will concentrate on for now.

> A (rather dull) job I need to do is to get the manuals converted into usable html format, since my intention is to have all the manuals online instead of published. To do that, I ran all the .pdf files through adobe's pdf->html translator. Unfortunately, their software did a terrible job - the text is all there, but the formatting is a mess. All the html files need to  be gone through line by line and the formatting corrected by hand. Ugh. I could just say "use the .pdf files", but I don't like using them and I doubt other net people do either.
> 

pdf format is acceptable for myself. However it does cause problems when updating the manuals.

> The printf and scanf functions need to be upgraded to support 80 bit long doubles and hex floats. Any library changes need to be accompanied with test programs to verify that they work.
> 
> I want to sort out and reorganize the library source tree so the old cruft is shunted aside and just the win32 stuff remains, and make it easier to build the library.
> 

Will the new ANSI C++ header names be required? A work around exists via STLport.

I think all the required changes need to be identified in some way, in smallish chucks so that those that wish to help can do so.

We probably need to ensure that there is no duplication of effort.

> Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
> SMAKE).
> 

Why not use make that is part of the GNU tools?

> At issue also would be the compensation for any work people do that is on proprietary stuff. Due to licensing issues, I can't make it open source, nor can I transfer copyrights.
> 
> 
There may be another way round this issue. Have a look at www.openwatcom.org.

But then again compensation in one form or another can be a good motivator :->

Damian

>
>
> > Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues with
> > SMAKE).
> >
>
> Why not use make that is part of the GNU tools?

While very powerful, the GNU make is significantly different from make programs
with a DOS heritage, e.g., nmake, borland make, and smake. I had to do a completely different
makefile for my project to cope with GNU make, while I was able to handle diferences
between the others with conditionals.

Edward F. Sowell <sowelled@home.com> wrote in message news:3A649228.E21538F0@home.com...
> >
> >
> > > Rewrite the makefiles to use MAKE instead of SMAKE. (Licensing issues
with
> > > SMAKE).
> > >
> >
> > Why not use make that is part of the GNU tools?
>
> While very powerful, the GNU make is significantly different from make
programs
> with a DOS heritage, e.g., nmake, borland make, and smake. I had to do a
completely different
> makefile for my project to cope with GNU make, while I was able to handle
diferences
> between the others with conditionals.
>
Granted. However it is free to use and emulates the UNIX make quite well.

Damian Dixon wrote:

>
> Granted. However it is free to use and emulates the UNIX make quite well.

Agreed. But if we talking about a niche for DMC, which I understand will NOT be free, perhaps it should not be aimed at the UNIX crowd. They will simply use

ALL of the GNU stuff, free. OTOH, there might be a demand for a MS alternative development system that is comfortable for the Windows people.

My 2 cents!

Ed Sowell

The MAKE I have also has some customizations to make it work well with the other tools I wrote. In particular, it handles arbitrarilly long command lines, while other MAKEs are limited to the NT command line max of 255 characters.


Edward F. Sowell wrote in message <3A64DC64.2E50F13A@home.com>...
>
>
>Damian Dixon wrote:
>
>>
>> Granted. However it is free to use and emulates the UNIX make quite well.
>
>Agreed. But if we talking about a niche for DMC, which I understand will
NOT
>be free, perhaps it should not be aimed at the UNIX crowd. They will simply
use
>
>ALL of the GNU stuff, free. OTOH, there might be a demand for a MS
alternative
>development system that is comfortable for the Windows people.
>
>My 2 cents!
>
>Ed Sowell
>
>

On Tue, 16 Jan 2001 17:16:14 -0800, "Walter" <walter@digitalmars.com> wrote:
> The MAKE I have also has some customizations to make it work well with the other tools I wrote. In particular, it handles arbitrarilly long command lines, while other MAKEs are limited to the NT command line max of 255 characters.
> 

ok, we will go with Walter's make :)

Just could not stop myself mentioning the other one!

Probably should have as this has side tracked the real issue of how to manage the required changes that Walter may wish people to help with.

> 
> Edward F. Sowell wrote in message <3A64DC64.2E50F13A@home.com>...
> >
> >
> >Damian Dixon wrote:
> >
> >>
> >> Granted. However it is free to use and emulates the UNIX make quite well.
> >
> >Agreed. But if we talking about a niche for DMC, which I understand will
> NOT
> >be free, perhaps it should not be aimed at the UNIX crowd. They will simply
> use
> >
> >ALL of the GNU stuff, free. OTOH, there might be a demand for a MS
> alternative
> >development system that is comfortable for the Windows people.

Not really true. We used to, but nearly all of our customers now use the compilers
produced by the OS manufacturers. Very few of our projects are now on Unix.
The one I am currently working on finishes in May, and that's it no more Unix
projects, other then porting from NT to Unix. The main reason I like using DMC++
is the correctness of the code and libraries. I've had too many problems with M$
VC++, which has meant that I have had to disassemble the code produced to
figure out what has gone wrong.

> >
> >My 2 cents!
> >
> >Ed Sowell
> >
> >
> 
>