Menu
▾
▴
dcplusplus-devel
|
From: poy <po...@12...> - 2008-05-17 23:54:42
|
note; mostly because of the boost updating, the patch is huge (50 MB) so i've uploaded it here: http://www.sendspace.com/file/8htnse since the MSVC people recently released the final version of their tr1 add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must say i've been pleasantly surprised by the fact that it took few changes (code-wise) for DC++ to be compilable with MSVC again. moreover, there is no added work-around; changes suggested/forced by MSVC actually all make sense. besides minor changes here and there, the patch fixes the following in order to make DC++ compilable with MSVC (it's roughly a change-log of what i had to do...): - SCons was always using MinGW and the Environment creation wasn't correct after my recent help changes; fixed. - updated boost to 1.35 and added the fusion/ sub-directory, required when compiling with MSVC. - include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and MSVC/STLPort use <X>). - operator() had to be const in dwt dispatchers. - added precompiled header generation with MSVC using the SCons PCH builder. - fixed some duplicate IDC_STATIC ids, and made 3 more strings translatable. - openssl: added .lib files in openssl/lib compiled statically with MASM (optimized); updated include files to the latest version. - intl: gettext tools can't be compiled with MSVC anymore ("MS Visual C/C++ with "nmake" is no longer supported." in the gettext win32-readme), so i've downloaded compiled .lib and .dll intl files from http://www.gtk.org/download-windows.html and that library is dynamically linked when compiling with MSVC (see comments in intl/SConscript). - added a little trick to add a Common Controls 6 manifest directly in the exe. - updated Compile.txt; there's a link to that tr1 feature pack. i've stated that MSVC is supported again (provided that one has MSVC 9 and the tr1 add-on) and boost/STLPort means of getting tr1 containers are deprecated. poy |
|
From: poy <po...@12...> - 2008-05-21 18:33:20
|
i have tried again using the boost folder from the current repository, and it appears the include error was much easier to solve than updating all boost files... all i had to do was make the "BOOST_HAS_GCC_TR1" define available for MSVC too (yes, it doesn't sound correct, but boost assumes you have all tr1 containers only in that case; that's up to future boost versions to fix that...). note; when compiling with MSVC 9, boost warns "Unknown compiler version - please run the configure tests and report the results". this is not important, and upgrading boost to 1.35 would remove the warning. the new patch is much lighter and hopefully easier to read. its 1MB+ size is caused by the pre-compiled openssl libraries that are included. the mailing-list still won't accept it so it's here: http://www.sendspace.com/file/gmlr5h poy ----- Original Message ----- From: "poy" <po...@12...> To: "dcplusplus-devel" <dcp...@li...> Sent: Sunday, May 18, 2008 1:52 AM Subject: [dcplusplus-devel] patch: MSVC compiling > note; mostly because of the boost updating, the patch is huge (50 MB) so > i've uploaded it here: http://www.sendspace.com/file/8htnse > > since the MSVC people recently released the final version of their tr1 > add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must > say i've been pleasantly surprised by the fact that it took few changes > (code-wise) for DC++ to be compilable with MSVC again. moreover, there is > no > added work-around; changes suggested/forced by MSVC actually all make > sense. > besides minor changes here and there, the patch fixes the following in > order > to make DC++ compilable with MSVC (it's roughly a change-log of what i had > to do...): > > - SCons was always using MinGW and the Environment creation wasn't correct > after my recent help changes; fixed. > > - updated boost to 1.35 and added the fusion/ sub-directory, required when > compiling with MSVC. > > - include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and > MSVC/STLPort use <X>). > > - operator() had to be const in dwt dispatchers. > > - added precompiled header generation with MSVC using the SCons PCH > builder. > > - fixed some duplicate IDC_STATIC ids, and made 3 more strings > translatable. > > - openssl: added .lib files in openssl/lib compiled statically with MASM > (optimized); updated include files to the latest version. > > - intl: gettext tools can't be compiled with MSVC anymore ("MS Visual > C/C++ > with "nmake" is no longer supported." in the gettext win32-readme), so > i've > downloaded compiled .lib and .dll intl files from > http://www.gtk.org/download-windows.html and that library is dynamically > linked when compiling with MSVC (see comments in intl/SConscript). > > - added a little trick to add a Common Controls 6 manifest directly in the > exe. > > - updated Compile.txt; there's a link to that tr1 feature pack. i've > stated > that MSVC is supported again (provided that one has MSVC 9 and the tr1 > add-on) and boost/STLPort means of getting tr1 containers are deprecated. > > poy > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > dcplusplus-devel mailing list > dcp...@li... > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel > > |
|
From: Jacek S. <arn...@gm...> - 2008-05-22 19:36:42
|
Please commit boost and openssl upgrade, const / other minor code fixes that also work for gcc don't include unsorted* all over dwt - create a dwt_unsorted* and include that instead I still need to think about the added libs (compiled openssl, intl, etc), and what implications that might have... /J poy wrote: > i have tried again using the boost folder from the current repository, and > it appears the include error was much easier to solve than updating all > boost files... all i had to do was make the "BOOST_HAS_GCC_TR1" define > available for MSVC too (yes, it doesn't sound correct, but boost assumes you > have all tr1 containers only in that case; that's up to future boost > versions to fix that...). > > note; when compiling with MSVC 9, boost warns "Unknown compiler version - > please run the configure tests and report the results". this is not > important, and upgrading boost to 1.35 would remove the warning. > > the new patch is much lighter and hopefully easier to read. its 1MB+ size is > caused by the pre-compiled openssl libraries that are included. > > the mailing-list still won't accept it so it's here: > http://www.sendspace.com/file/gmlr5h > > poy > > ----- Original Message ----- > From: "poy" <po...@12...> > To: "dcplusplus-devel" <dcp...@li...> > Sent: Sunday, May 18, 2008 1:52 AM > Subject: [dcplusplus-devel] patch: MSVC compiling > > >> note; mostly because of the boost updating, the patch is huge (50 MB) so >> i've uploaded it here: http://www.sendspace.com/file/8htnse >> >> since the MSVC people recently released the final version of their tr1 >> add-on for MSVC 9 (2008), i tried to compile DC++ again with MSVC. i must >> say i've been pleasantly surprised by the fact that it took few changes >> (code-wise) for DC++ to be compilable with MSVC again. moreover, there is >> no >> added work-around; changes suggested/forced by MSVC actually all make >> sense. >> besides minor changes here and there, the patch fixes the following in >> order >> to make DC++ compilable with MSVC (it's roughly a change-log of what i had >> to do...): >> >> - SCons was always using MinGW and the Environment creation wasn't correct >> after my recent help changes; fixed. >> >> - updated boost to 1.35 and added the fusion/ sub-directory, required when >> compiling with MSVC. >> >> - include fixes for tr1 containers in dwt (since GCC uses <tr1/X> and >> MSVC/STLPort use <X>). >> >> - operator() had to be const in dwt dispatchers. >> >> - added precompiled header generation with MSVC using the SCons PCH >> builder. >> >> - fixed some duplicate IDC_STATIC ids, and made 3 more strings >> translatable. >> >> - openssl: added .lib files in openssl/lib compiled statically with MASM >> (optimized); updated include files to the latest version. >> >> - intl: gettext tools can't be compiled with MSVC anymore ("MS Visual >> C/C++ >> with "nmake" is no longer supported." in the gettext win32-readme), so >> i've >> downloaded compiled .lib and .dll intl files from >> http://www.gtk.org/download-windows.html and that library is dynamically >> linked when compiling with MSVC (see comments in intl/SConscript). >> >> - added a little trick to add a Common Controls 6 manifest directly in the >> exe. >> >> - updated Compile.txt; there's a link to that tr1 feature pack. i've >> stated >> that MSVC is supported again (provided that one has MSVC 9 and the tr1 >> add-on) and boost/STLPort means of getting tr1 containers are deprecated. >> >> poy >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> dcplusplus-devel mailing list >> dcp...@li... >> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > dcplusplus-devel mailing list > dcp...@li... > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel > |
|
From: poy <po...@12...> - 2008-05-22 21:19:33
|
> Please commit boost and openssl upgrade, const / other minor code fixes > that also work for gcc i've committed all of it except the intl and openssl changes; you may want to read the paragraph about tr1 i've added in Compile.txt. on boost upgrade: are there any particular changes to do in the boost/ dir once it's updated? it works fine by simply updating but still... on openssl upgrade: should the libs in openssl/lib be updated too? it works fine by simply updating header files in openssl/include but still... poy |
|
From: Jacek S. <arn...@gm...> - 2008-05-23 07:45:10
|
poy wrote: >> Please commit boost and openssl upgrade, const / other minor code fixes >> that also work for gcc > > i've committed all of it except the intl and openssl changes; you may want > to read the paragraph about tr1 i've added in Compile.txt. > on boost upgrade: are there any particular changes to do in the boost/ dir > once it's updated? it works fine by simply updating but still... Not really - I can't decide whether it's better to add just the bare minimum we need or everything - in the first case scons works faster, in the second it's easier to update...overall I'd prefer the first option - one fine day I must have a look at how to make scons skip scanning the boost headers for changes when doing its dep scan... > on openssl upgrade: should the libs in openssl/lib be updated too? it works > fine by simply updating header files in openssl/include but still... Definately - otherwise it's still the old version of the actual code (without whatever fixes they put in between the versions)! > poy > > |
|
From: Michael J. <mrm...@ho...> - 2008-06-20 15:07:48
|
Just got a few queries / suggestions . . . . In October i sent in a patch to this mailing list to remove a lot of white space from the source code, but since it was so big, it needed to be "authorized" or something. Since a lot has changed in the source since then, the old one i did is useless and will need to be redone (and never turned up here). So to prevent this issue in the future can i commit whitespace removal directly, or should i open a launchpad bug report, which could always stay open and just receive patches for removing white space ? On a side note with this, i remember that in the copy write notice on the top of all the DC++ files there was a full stop followed by two spaces, it would make white space finding and removal a lot easier if this was changed to one space following the full stop. So in a future whitespace patch, would it be acceptable to remove this extra space from the copy write notices ? Regarding cross compiling, when i was using 32bit ubuntu, and now on 64bit debian this had to be added to the command line scons call prefix=i586-mingw32msvc- whereas on compiling with windows it isn't needed. So could a SConscript change be made so that if OS == Windows, leave as is, and if OS == Linux automatically use that prefix. Just to make it nicer / easier. Or is there a case where i386 mingw maybe used on Linux ? Regarding translations, FleetCommand mentioned earlier that BCDC uses PM in the time sense, and this could conflict with the User Commands page occurrence of PM (for Private Message), and i thought in this case, the User Commands one could just be changed to Private Message. This also got me thinking, since BCDC uses launchpad now for the bzr repository, they have to sync translations with DC++'s updates. Whereas DC++ has the nice launchpad translation page, BCDC is deprived of this. To make this nicer for branches / mod's of DC++ i thought that a "dummy.cpp" file could be added to both dcpp and win32 directories, which is skipped from compiling, but scanned by gettext. This would mean that if mod authors could put text's in there, to be translated, and would turn up on the launchpad's translation page. And it wouldn't / shouldn't affect DC++ adversely. thanks MikeJJ _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/ |
|
From: Jacek S. <arn...@gm...> - 2008-06-22 09:33:23
|
Michael Jones wrote: > Just got a few queries / suggestions . . . . > > In October i sent in a patch to this mailing list to remove a lot of white space from the source code, but since it was so big, it needed to be "authorized" or something. Since a lot has changed in the source since then, the old one i did is useless and will need to be redone (and never turned up here). So to prevent this issue in the future can i commit whitespace removal directly, or should i open a launchpad bug report, which could always stay open and just receive patches for removing white space ? Commit janitorial tasks directly > On a side note with this, i remember that in the copy write notice on the top of all the DC++ files there was a full stop followed by two spaces, it would make white space finding and removal a lot easier if this was changed to one space following the full stop. So in a future whitespace patch, would it be acceptable to remove this extra space from the copy write notices ? Feel free to remove any redundant whitespace (and convert spaces to tabs where needed, assuming 4 spaces per tab. > Regarding cross compiling, when i was using 32bit ubuntu, and now on 64bit debian this had to be added to the command line scons call > prefix=i586-mingw32msvc- > whereas on compiling with windows it isn't needed. > So could a SConscript change be made so that if OS == Windows, leave as is, and if OS == Linux automatically use that prefix. Just to make it nicer / easier. > Or is there a case where i386 mingw maybe used on Linux ? It depends on the linux distribution...debian uses i386 for example...you can put that (or any) option in a file called custom.py: ------ cut prefix = "blabla" ------ cut > Regarding translations, FleetCommand mentioned earlier that BCDC uses PM in the time sense, and this could conflict with the User Commands page occurrence of PM (for Private Message), and i thought in this case, the User Commands one could just be changed to Private Message. > This also got me thinking, since BCDC uses launchpad now for the bzr repository, they have to sync translations with DC++'s updates. Whereas DC++ has the nice launchpad translation page, BCDC is deprived of this. To make this nicer for branches / mod's of DC++ i thought that a "dummy.cpp" file could be added to both dcpp and win32 directories, which is skipped from compiling, but scanned by gettext. This would mean that if mod authors could put text's in there, to be translated, and would turn up on the launchpad's translation page. And it wouldn't / shouldn't affect DC++ adversely. Mods should keep their own translation pages - I don't want to burden translators with extra work that they might not want to do. |
|
From: poy <po...@12...> - 2008-05-23 10:08:49
Attachments:
patch.patch
|
i've looked into the errors i was getting when trying to build intl/ with MSVC and they were pretty easy to solve; it was only a matter of changing #define's in config.h. so using precompiled libraries may not be needed after all. :) in the attached patch i've created 2 config.h files, 1 for each compiler; to avoid having "#ifdef compiler"s all over the config file. also, tsearch added as MSVC needs it. things should remain exactly the same as before when using GCC. poy |
|
From: Jacek S. <arn...@gm...> - 2008-05-23 07:57:16
|
poy wrote: >> Please commit boost and openssl upgrade, const / other minor code fixes >> that also work for gcc > > i've committed all of it except the intl and openssl changes; you may want > to read the paragraph about tr1 i've added in Compile.txt. oh, and tr1 containers (unordered*) are not part of boost (yet)... /J |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X