SOC Project Idea: Winelib-aware scons
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project. Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported. Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible. As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents. I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine 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. Thanks, Scott Ritchie
Hello, If you don't mind using CMake ( http://cmake.org ) instead of Scons, here is a starting point: http://dgwarp.hd.free.fr/vcproj2cmake.rb On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported.
Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible.
As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents.
I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine
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.
Thanks, Scott Ritchie
-- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
2009/3/21 Pau Garcia i Quiles <pgquiles(a)elpauer.org>:
Hello,
If you don't mind using CMake ( http://cmake.org ) instead of Scons, here is a starting point:
http://dgwarp.hd.free.fr/vcproj2cmake.rb
On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported.
Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible.
As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents.
I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine
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.
Thanks, Scott Ritchie
There are so many different build systems. Classic Make, GNU Make, scons, setuptools ... there must be plenty I don't know about too. A framework for adapting Visual Studio projects to some generic format which can then be processed into whatever native make-like system you want would probably be the way to go, but also involve a *lot* more work than just making a scons or CMake variant :)
On Fri, Mar 20, 2009 at 10:21 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/3/21 Pau Garcia i Quiles <pgquiles(a)elpauer.org>:
Hello,
If you don't mind using CMake ( http://cmake.org ) instead of Scons, here is a starting point:
http://dgwarp.hd.free.fr/vcproj2cmake.rb
On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported.
Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible.
As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents.
I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine
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.
Thanks, Scott Ritchie
There are so many different build systems. Classic Make, GNU Make, scons, setuptools ... there must be plenty I don't know about too. A framework for adapting Visual Studio projects to some generic format which can then be processed into whatever native make-like system you want would probably be the way to go, but also involve a *lot* more work than just making a scons or CMake variant :)
Monodevelop can open and use Visual Studio projects. It may be a useful foundation to build a plugin on that would accomplish the goal of building directly from the existing solution. I think it can open vs2003 and beyond but only works well with vs2005 and beyond. I use it all of the time to build .net projects both from the gui and from the command line. Chris
On Fri, Mar 20, 2009 at 11:42 PM, Chris Morgan <chmorgan(a)gmail.com> wrote:
On Fri, Mar 20, 2009 at 10:21 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/3/21 Pau Garcia i Quiles <pgquiles(a)elpauer.org>:
Hello,
If you don't mind using CMake ( http://cmake.org ) instead of Scons, here is a starting point:
http://dgwarp.hd.free.fr/vcproj2cmake.rb
On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported.
Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible.
As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents.
I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine
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.
Thanks, Scott Ritchie
There are so many different build systems. Classic Make, GNU Make, scons, setuptools ... there must be plenty I don't know about too. A framework for adapting Visual Studio projects to some generic format which can then be processed into whatever native make-like system you want would probably be the way to go, but also involve a *lot* more work than just making a scons or CMake variant :)
Monodevelop can open and use Visual Studio projects. It may be a useful foundation to build a plugin on that would accomplish the goal of building directly from the existing solution. I think it can open vs2003 and beyond but only works well with vs2005 and beyond. I use it all of the time to build .net projects both from the gui and from the command line.
Chris
For C/C++ projects, Code::Blocks can open and use Visual Studio projects, and that might be more useful since I don't think Winelib is supposed to deal with .NET code ;) The VS solution importer in Code::Blocks uses a lexar xml file for rules on importing I think, so it could be adapted to winemaker.
King InuYasha schrieb:
On Fri, Mar 20, 2009 at 11:42 PM, Chris Morgan <chmorgan(a)gmail.com <mailto:chmorgan(a)gmail.com>> wrote:
On Fri, Mar 20, 2009 at 10:21 PM, Ben Klein <shacklein(a)gmail.com <mailto:shacklein(a)gmail.com>> wrote: > 2009/3/21 Pau Garcia i Quiles <pgquiles(a)elpauer.org <mailto:pgquiles(a)elpauer.org>>: >> Hello, >> >> If you don't mind using CMake ( http://cmake.org ) instead of Scons, >> here is a starting point: >> >> http://dgwarp.hd.free.fr/vcproj2cmake.rb >> >> On Sat, Mar 21, 2009 at 12:50 AM, Scott Ritchie <scott(a)open-vote.org <mailto:scott(a)open-vote.org>> wrote: >>> For a while now I've been hoping someone would tackle a pet project of >>> mine. It occurred to me that it would be a great summer of code project. >>> >>> Basically, I want a magic script that can convert a visual studio >>> project file into a winelib-aware, scons-powered, linux-compatible build >>> system. This would make it very easy for a Windows-only Visual Studio >>> project to be ported. >>> >>> Now, normally, someone writing portable code would probably want to use >>> scons from the start instead of Visual Studio, but Winelib throws a monkey >>> wrench into this process by making formerly non-portable code suddenly Linux >>> compatible. >>> >>> As a good example application to test, the program eMule would be a good >>> candidate - it's open source, works great in Wine, is built with Visual >>> Studio, and has no good native equivalents. >>> >>> I've added a work in progress wiki page on the Wine wiki here: >>> http://wiki.winehq.org/SconsWine >>> >>> >>> >>> 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. >>> >>> >>> Thanks, >>> Scott Ritchie > > There are so many different build systems. Classic Make, GNU Make, > scons, setuptools ... there must be plenty I don't know about too. A > framework for adapting Visual Studio projects to some generic format > which can then be processed into whatever native make-like system you > want would probably be the way to go, but also involve a *lot* more > work than just making a scons or CMake variant :) >
Monodevelop can open and use Visual Studio projects. It may be a useful foundation to build a plugin on that would accomplish the goal of building directly from the existing solution. I think it can open vs2003 and beyond but only works well with vs2005 and beyond. I use it all of the time to build .net projects both from the gui and from the command line.
Chris
For C/C++ projects, Code::Blocks can open and use Visual Studio projects, and that might be more useful since I don't think Winelib is supposed to deal with .NET code ;)
The VS solution importer in Code::Blocks uses a lexar xml file for rules on importing I think, so it could be adapted to winemaker. ------------------------------------------------------------------------
i would prefer Code::Blocks too. The last thing which makes problems is MFC. winelib can't handle MFC...maybe we should include wxwidgets. a good mfc2wx converter would be great. i am thinking about to do this the last weeks. winemaker also will handle vcproj and dsp when my patch gets commited.
On Mar 20, 2009, at 4:50 PM, Scott Ritchie wrote:
... 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.
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. 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. 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. 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. 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. 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. 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. Hope this helps, -- Greg Noel, retired UNIX guru
On Sat, Mar 21, 2009 at 10:42 AM, Greg Noel <GregNoel(a)tigris.org> wrote:
On Mar 20, 2009, at 4:50 PM, Scott Ritchie wrote:
... 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.
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.
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.
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.
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.
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.
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.
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.
Hope this helps, -- Greg Noel, retired UNIX guru
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. I checked, and it doesn't look like C::B has a XML rules file for project importing. However, I did find the sources for the project importer, which can import *.dsw, *.dsp, *.sln, and *.vcproj files. Link: http://svn.berlios.de/svnroot/repos/codeblocks/trunk/src/plugins/projectsimp... It might help, it might not. I dunno really.
On Mar 22, 2009, at 4:47 AM, King InuYasha wrote:
Does SCons support the project-within-a-project build style that is used in Visual Studio? ...
SCons is amazingly policy-neutral, and we work to keep it that way. (It has occasionally been a bone of contention, when people have wanted us to support a particular development model by enforcing rules to exclude other styles.) In other words, there's nothing to prevent the VS style, although there's nothing that specifically "supports" it, either.
Additionally, since a lot of sources have mixed case, you would need to have some sort of check for that built into the analysis. ...
I think this is what concerns me more than anything else. I don't think SCons itself should be in the business of auto-magically converting sources. Maybe providing tools to help the user convert, but even that is pushing the envelope.
... I did find the sources for the project importer, ...
Unfortunately, that's in C++ and we're a pure Python shop. Moreover, I suspect the license is incompatible (it seems to use the GNU virus, while we use the MIT license). But it's a useful reference and I'll hang on to it; thanks. Hope this helps, -- Greg Noel, retired UNIX guru
On Sat, 21 Mar 2009, Greg Noel wrote: [...]
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.
The Winelib tools (winebuild, winegcc, wrc, widl, etc) are actually used everyday and are under active development as they are used to build Wine itself. What is not under active development is the tools to automatically convert Windows projects / source code into something that can be compiled using the Wine build tools. This is winemaker's task and André Hentschel has been recently submitting patches to add support for converting Visual Studio projects to regular makefiles (and I have been slacking on providing feedback, sorry). The other thing that's not under active development is the documentation. But none of that should be an issue for someone writing a dsp/vcproj to SCons converter. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
On Mar 22, 2009, at 11:18 AM, Francois Gouget wrote:
The Winelib tools (winebuild, winegcc, wrc, widl, etc) are actually used everyday [sic] and are under active development as they are used to build Wine itself.
Ah, I didn't know that. I thought winelib was more like a replacement for the SDK. (And maybe it's that, too; as a UNIX weenie, I'm well outside my knowledge base here.)
What is not under active development is the tools to automatically convert Windows projects / source code into something that can be compiled using the Wine build tools. ...
I think I begin to understand. And I'd guess that's why Scott described it as a converter, not as built-in functionality.
But none of that should be an issue for someone writing a dsp/vcproj to SCons converter.
True, but that project would be less appealing to us, as it wouldn't require the student to open our code base (or yours, for that matter), and what we'd like is for the student to evolve into a regular contributor. Hope this helps, -- Greg Noel, retired UNIX guru
On Fri, Mar 20, 2009 at 7:50 PM, Scott Ritchie <scott(a)open-vote.org> wrote:
For a while now I've been hoping someone would tackle a pet project of mine. It occurred to me that it would be a great summer of code project.
Basically, I want a magic script that can convert a visual studio project file into a winelib-aware, scons-powered, linux-compatible build system. This would make it very easy for a Windows-only Visual Studio project to be ported.
Now, normally, someone writing portable code would probably want to use scons from the start instead of Visual Studio, but Winelib throws a monkey wrench into this process by making formerly non-portable code suddenly Linux compatible.
As a good example application to test, the program eMule would be a good candidate - it's open source, works great in Wine, is built with Visual Studio, and has no good native equivalents.
I've added a work in progress wiki page on the Wine wiki here: http://wiki.winehq.org/SconsWine
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.
Thanks, Scott Ritchie
I replied later in this thread but I wanted to again make the case for a plugin to Monodevelop. There are a few good reasons for starting with monodevelop. The website is at http://monodevelop.com/Main_Page - Can read and write visual studio solution and project files. Enables a user to modify the project under MD without breaking VS. (Supports nested projects that Greg Noel mentioned recently). Consider the value of enabling a user to maintain their existing solution and project files. Having to convert build files means maintaining parallel build systems. - IDE similar to Visual studio, code completion etc (also has a command line build tool) - Plugin based architecture. Has a gui plugin manager that would make it easy for users to install a winelib plugin. - Written in c#, simplifies things like memory management If the goal is to make porting to winelib easier, consider the value of providing a similar IDE experience to that on windows. A lot of the discussion has focused on things like reading/writing or converting file formats. Using MD means having an existing path to follow in parsing and building the solutions and projects. I'm sure there are more important aspects to deal with other than the mechanics of file formats. Chris
participants (8)
-
André Hentschel -
Ben Klein -
Chris Morgan -
Francois Gouget -
Greg Noel -
King InuYasha -
Pau Garcia i Quiles -
Scott Ritchie