Is there any reason why there can't be a dmc/gmake target in the wx bakefiles?  The official story seems to be that the dmars target is crippled because dmars make is crippled.  But why bother with dmars make when there are at least three free ports of gnumake for win32 out there that I know of [1].

Is there some mystery magic that lurks within dmars' make that can't be duplicated in gnumake?


[1] cygwin, MSYS, and gnuwin32

--bb

Hi, I suggest you buy smake

Extended Utilities Package  at http://www.digitalmars.com/eup.html

and use smake -makefile.dms

Walter is very good at fixing bugs, so we do need to use his tools.

chris

Bill Baxter wrote:
> Is there any reason why there can't be a dmc/gmake target in the wx bakefiles?  The official story seems to be that the dmars target is crippled because dmars make is crippled.  But why bother with dmars make when there are at least three free ports of gnumake for win32 out there that I know of [1].
> 
> Is there some mystery magic that lurks within dmars' make that can't be duplicated in gnumake?
> 
> 
> [1] cygwin, MSYS, and gnuwin32
> 
> --bb

Yes, you're probably right.  Spending $15 for something I don't really need is probably a better value proposition than spending 20 hours trying to implement something I don't really need.

But the question remains, is there anything preventing one from implementing a dmars_gmake bakefile target?  It doesn't seem like it should be that difficult to make a hybrid out of the mingw bakefiles and dmars bakefiles, given familiarity with how bakefile works.

You're right -- I'm probably not going to do it, but the answer to the above question tells me something about the flexibility of the bakefile system, and that's of interest to me.  And doing it could be a good way to get acquainted with bakefile's internals.

--bb

chris elliott wrote:
> Hi, I suggest you buy smake
> 
> Extended Utilities Package  at http://www.digitalmars.com/eup.html
> 
> and use smake -makefile.dms
> 
> Walter is very good at fixing bugs, so we do need to use his tools.
> 
> chris
> 
> Bill Baxter wrote:
>> Is there any reason why there can't be a dmc/gmake target in the wx bakefiles?  The official story seems to be that the dmars target is crippled because dmars make is crippled.  But why bother with dmars make when there are at least three free ports of gnumake for win32 out there that I know of [1].
>>
>> Is there some mystery magic that lurks within dmars' make that can't be duplicated in gnumake?
>>
>>
>> [1] cygwin, MSYS, and gnuwin32
>>
>> --bb

Bill Baxter wrote:
> Yes, you're probably right.  Spending $15 for something I don't really need is probably a better value proposition than spending 20 hours trying to implement something I don't really need.
> 
> But the question remains, is there anything preventing one from implementing a dmars_gmake bakefile target?  It doesn't seem like it should be that difficult to make a hybrid out of the mingw bakefiles and dmars bakefiles, given familiarity with how bakefile works.
> 
> You're right -- I'm probably not going to do it, but the answer to the above question tells me something about the flexibility of the bakefile system, and that's of interest to me.  And doing it could be a good way to get acquainted with bakefile's internals.

To answer my own question, yes, DMC w/ gnu make works fine.  Took me only about an hour of work (starting from knowing basically nothing about bakefile) to create a hybrid of the bakefile defs files, and to modify the wx bkl files accordingly.  The new target is called dmars_gnu.

My motivation for this is helping out the wxD project.  In order to use wxD you have to build wxWidgets using dmc.  It already takes too many steps to build and install wxD.  Requiring one of those steps to be "download bakefile just so you can regenerate makefiles for the version of wx you want to build -- or buy the EUP for smake" is a little annoying.

--bb

Bill Baxter wrote:
> Bill Baxter wrote:
>> Yes, you're probably right.  Spending $15 for something I don't really need is probably a better value proposition than spending 20 hours trying to implement something I don't really need.
>>
>> But the question remains, is there anything preventing one from implementing a dmars_gmake bakefile target?  It doesn't seem like it should be that difficult to make a hybrid out of the mingw bakefiles and dmars bakefiles, given familiarity with how bakefile works.
>>
>> You're right -- I'm probably not going to do it, but the answer to the above question tells me something about the flexibility of the bakefile system, and that's of interest to me.  And doing it could be a good way to get acquainted with bakefile's internals.
> 
> To answer my own question, yes, DMC w/ gnu make works fine.  Took me only about an hour of work (starting from knowing basically nothing about bakefile) to create a hybrid of the bakefile defs files, and to modify the wx bkl files accordingly.  The new target is called dmars_gnu.
> 
> My motivation for this is helping out the wxD project.  In order to use wxD you have to build wxWidgets using dmc.  It already takes too many steps to build and install wxD.  Requiring one of those steps to be "download bakefile just so you can regenerate makefiles for the version of wx you want to build -- or buy the EUP for smake" is a little annoying.

Oh foo.  Nevermind. It doesn't work.  The libraries build and go to the right places but none of the samples will link properly.

--bb

I still use the IDDE... and not the bakefiles...
wxWidgets 2.8.x compiles fine in the IDDE (if you want the files... )
samples build just file with the IDDE...

Jan



Bill Baxter wrote:
> Bill Baxter wrote:
>> Bill Baxter wrote:
>>> Yes, you're probably right.  Spending $15 for something I don't really need is probably a better value proposition than spending 20 hours trying to implement something I don't really need.
>>>
>>> But the question remains, is there anything preventing one from implementing a dmars_gmake bakefile target?  It doesn't seem like it should be that difficult to make a hybrid out of the mingw bakefiles and dmars bakefiles, given familiarity with how bakefile works.
>>>
>>> You're right -- I'm probably not going to do it, but the answer to the above question tells me something about the flexibility of the bakefile system, and that's of interest to me.  And doing it could be a good way to get acquainted with bakefile's internals.
>>
>> To answer my own question, yes, DMC w/ gnu make works fine.  Took me only about an hour of work (starting from knowing basically nothing about bakefile) to create a hybrid of the bakefile defs files, and to modify the wx bkl files accordingly.  The new target is called dmars_gnu.
>>
>> My motivation for this is helping out the wxD project.  In order to use wxD you have to build wxWidgets using dmc.  It already takes too many steps to build and install wxD.  Requiring one of those steps to be "download bakefile just so you can regenerate makefiles for the version of wx you want to build -- or buy the EUP for smake" is a little annoying.
> 
> Oh foo.  Nevermind. It doesn't work.  The libraries build and go to the right places but none of the samples will link properly.
> 
> --bb


-- 
ManiaC++
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.

www.smartsoft.us

Phone : 609-628-4260
FAX   : 609-628-1267
Y!    : janknepper

But as for me and my household, we shall use Mozilla...
www.mozilla.org
Get legal - Get OpenOffice.org www.openoffice.org

Hi,

Jan Knepper wrote:
> I still use the IDDE... and not the bakefiles...
> wxWidgets 2.8.x compiles fine in the IDDE (if you want the files... )
> samples build just file with the IDDE...
> 

Is x in 2.8.x apply to 2.8.8 or 2.8.9? If so, I want your files :)

ps-1. Recently, I post a message about getting "internal error: eh 759" for building 2.8.8 via makefile.dms.

ps-2. I tried to build 2.9.0 snapshot too. After some conversation at wxwindows list and compiling trial, Vadim Zeitlin (one of core developers of wx) wrote following:

HD> > HD> There is no file named shldisp.h in dm.
HD> >
HD> >  AFAICS all the rest is due to missing Platform SDK files/definitions. You
HD> > can either make a patch adding everything needed to the __DMC__ section of
HD> > include/wx/msw/missing.h or contribute the missing definitions to DMC
HD> > itself (preferred). We definitely don't want to work around each of them
HD> > individually in the wx sources, sorry.
HD>
HD> I understand. But, losting a free/good compiler option due to old PSDK
HD> makes me sorry..

 It's unfortunate but I don't see any other solution except using a newer
PSDK. It shouldn't be that difficult... Again, if you prefer to reproduce
all the missing stuff in __DMC__ section of missing.h -- why not. But IMO
this would be a waste of [your] time.



> Jan
> 
> 


--
Regards,
Hakki Dogusan