<div class="gmail_quote">On Sat, Mar 21, 2009 at 10:42 AM, Greg Noel <span dir="ltr"><<a href="mailto:GregNoel@tigris.org">GregNoel@tigris.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Mar 20, 2009, at 4:50 PM, Scott Ritchie wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. �... �I'm not sure whether this will function better as an scons summer of code project or a Wine one, nor am I sure where a student would be able to find a good mentor. �Accordingly, I'm emailing both mailing lists, and hoping for some feedback, particularly if it doesn't sound feasible.<br>
</blockquote>
<br>
I'm the primary GSoC admin for SCons, and all I can say is that the project doesn't sound infeasible---but that's not the same thing as saying that it's feasible.<br>
<br>
On the other hand, I'd wonder about viability. �It doesn't look like the basic winelib information has been updated since January 2005, although there's mention of a planned 0.9 release in September 2005. �That's more than three years of inactivity. �Over the last few months it looks like you've been trying to revitalize the project, but I'm not seeing a lot of traction. �If I were a student researching this idea, I'd be leery about proposing a project for a tool that appeared moribund.<br>
<br>
That said, there's the question the skill set a student would need. �He'd have to have a good understanding of VisualStudio (at least as far as its project file format, which I believe is XML), some graph theory to deal with the dependency graph, more knowledge of winelib than I was able to dig out in a few minutes of research, and some Python. �If we are primary on the project, we'd insist that the implementation language be Python, so that would require an even greater background in Python. �Some of the skills can be learned as part of the project (that's what it's about, after all), but the combination of VisualStudio and Python may be rare.<br>
<br>
The idea would be to open the VisualStudio control file, extract the dependency graph, and generate a SConscript with the equivalent flow. �Put that way, it's a week or two to do the work and maybe another week to write the documentation. �The result probably be useful, but it's not really of the scale we'd expect of a GSoC project, nor would it require opening the source for either project.<br>
<br>
More interesting would be to write a SCons builder that took a project file, did the analysis as in the previous paragraph, and inserted the build steps directly. �There's been some interest expressed in our community for something like this feature. �The build steps would be native on systems that had the appropriate SDK and use winelib otherwise. �That's still only a few weeks work, though.<br>
<br>
Those two tasks might be the foundation of a project proposal that also included some additional tasks. �An interesting third task would be to revamp our existing facility that creates VisualStudio project and solution files so that they don't just run SCons under the hood; in other words, that they contain the full dependency graph and SCons would not be needed to build the project.<br>
<br>
It does look like there's some fruitful ground in your suggestion, but I think it will take some more information (and reassurance) than what we have now. �I'm willing to add it to our ideas list if that can be worked out. �Let me know.<br>
<br>
Hope this helps,<br><font color="#888888">
-- Greg Noel, retired UNIX guru<br>
<br>
<br>
</font></blockquote></div><br><div>Does SCons support the project-within-a-project build style that is used in Visual Studio? I know that most UNIX buildsystems do not support the Visual Studio solution build method, so it would be rather difficult if you couldn't support *.dsw and *.sln files. Obviously, this would mean you would need to chain convert the project files and analyze sources recursively. Additionally, since a lot of sources have mixed case, you would need to have some sort of check for that built into the analysis. Granted, winemaker already provides the lowercasing functionality, but the actual source code itself needs to be analyzed and force all lowercase for file names in addition to correcting file paths.</div>
<div><br></div><div>I checked, and it doesn't look like C::B has a XML rules file for project importing.</div><div><br></div><div>However, I did find the sources for the project importer, which can import *.dsw, *.dsp, *.sln, and *.vcproj files.</div>
<div>Link:�<a href="http://svn.berlios.de/svnroot/repos/codeblocks/trunk/src/plugins/projectsimporter/">http://svn.berlios.de/svnroot/repos/codeblocks/trunk/src/plugins/projectsimporter/</a></div><div><br></div><div>It might help, it might not. I dunno really.</div>
<div><br></div><div><br></div>