[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[42257] scummvm/trunk/graphics

Norbert Lange lange at chello.at
Wed Jul 8 20:45:15 CEST 2009


Am 08.07.2009, 19:38 Uhr, schrieb Max Horn <max at quendi.de>:

>
> Am 08.07.2009 um 19:28 schrieb Filippos Karapetis:
>
> [...]
>
>>
>> 2) Add common includes for all engines, thereby greatly simplifying
>> the engine project files, and having everything
>> neatly packed in one common file for all MSVC project files. This
>> solves not only this problem, but many others too,
>> as all compilation options are in one file and not scattered among
>> different ones - this actually makes MSVC
>> compilation options a bit more similar to the GCC ones (i.e. they're
>> all in one place). This solution has been implemented
>> by nolange in the following rejected patch:
>> https://sourceforge.net/tracker/?func=detail&aid=2774908&group_id=37116&atid=418822
>> The main problem with this solution is that it's only supported in
>> MSVC8 and later (as described in the patch tracker
>> item), so we'll have to drop MSVC7 and MSVC7.1 - unless we move to
>> some better system than the batch files I've
>> made right now, i.e. cmake or similar
>
> As I stated before, it should be possible to write a perl/python/
> whatever script which takes our module.mk files and some extra bits,
> and auto-generates all the vcproj files for all MSVC versions from it.
> Of course, "somebody" would have to code it.
> Actually, it might be easier not to use the module.mk files but rather
> simply use all *.cpp and *.h files found in each engines/ subdir, and
> just hardcode the mapping (inside the new tool) of directories
> (graphics, engines/FOO, sound, gui, ...) to subprojects and likewise
> hardcode the settings for each subproject (i.e. optimization settings,
> ENABLE_FOO flags, etc.).
>
> This is a relatively easy task, I think -- you don't even need to have
> Windows for it, as the MSVC files are XML and generating them should
> be really easy. It wouldn't be very exciting easy, but would neatly
> solve the problem of outdated MSVC files once and for all ;).

It would need some hardcoded exceptions like files that have
inline-assembly (can only think of libmpeg2 now, not a good example as
this is already redundand). But definitly doable.
The proposed (and rejected) patch would cleanly seperate projects into
sets of files and global options, with the idea of making it easy to use
personal compiler-settings and have them applied everywhere.
It will also help generating those projects-files easier, but TBH if we go
the long way of coding tools for genrating them it shouldnt be hard to
make it spit out files for MSVC7 aswell.

Whats still a weak point is en/disabling engines within the IDE, with the
proposed patch you`d need to take care for the corresponding define and
en/disable compilation of the project aswell. There is no inbuilt way to
do this easier within the IDE. I think there might be some ways around
that to automatically generate the defines using prebuild/postbuild events
but Im not sure how hard that would be.

>> Personally, I vote for the second solution: it would be better to
>> drop support for older/strange compilers rather than
>> keeping compile options and defines scattered and duplicated in
>> several files. Also, not a lot of users use MSVC7 and
>> MSVC7.1 (I only know of 1, Quietusk).
>
> It would still be nice to get a slightly better idea on how many
> people out there are using MSVC 7 and why, and how bad dropping MSVC 7
> support would affect those.
Would be interested in knowing that myself, with free versions of MSVC9
available.

Regards, Norbert




More information about the Scummvm-devel mailing list