Hi binsys,

 

The dependencies are supposed to be between projects. For example, mspaint would be dependent upon libcomctrl32.lib. It is not possible to have dependencies between project if the IDE is not aware of the projects.

 

Indeed, VisualDDK is a good WinDBG functionality, and it was part of my original plan. J

 

-John

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of BinSys
Sent: Saturday, January 12, 2013 1:34 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 


If you open the the output-VS11-i386\reactos\ntoskrnl\NTOS.sln file, you will find that the dependence is not lost.Like this, each component has its own sln file, very convenient.Root sln file is still available.Only at the beginning of each CMakeLists.txt file a PROJECT (***).

 

In addition, VisualDDK very good the WinDBG functionality ported to the IDE.



At 2013-01-12 02:49:02,"J. C. Jones" <jaibuduvin@gmail.com> wrote:

It also takes quite a while to close: about 1 minute on my Virtual Box machine (1GB RAM) running inside i5/8GB.

 

Having a .sln file for each project would reduce the load time obviously, but that would  defeat the purpose of using an IDE. There is a natural workflow with the IDE. The idea is to capture that workflow. If the work flow is lost, then it makes more sense to go back to using Visual Studio as an editor, and building “manually”, because there is such a thing as the “productivity” tool becoming a burden itself..

 

I am wondering if the load-time can be reduced by reworking the project settings. From the moment I load the .sln, to the moment that I can start editing a .c file, there is a 48-second delay in the virtual machine above. Of course, during this delay, Visual Studio is:

1.       building internal dependency graphs based on #include files.

2.       building internal parse tree to support IntelliSense and other things.

As it stands, unless I am mistaken, the #include directories that are being specified to the IDE include superfluous paths, which would result in a (likely very small) performance increase based on directory searching alone. Here is the list of the #include directories for the calc application:

 

 

Here is a partial list of the #include file dependencies for calc. One can conclude that there might be dependencies that are superfluous:

 

 

This appears to be the case for several applications, including Notepad, which includes headers for cryptography and networking:

There are things that the programmer can do to reduce the pollution of the compiler’s parse tree. One should add the following macro to the compiler’s command-line when possible:

WIN32_LEAN_AND_MEAN

This #define disables entire blocks of /#ifdef,#include, #include, #include, #include, #include,#endif/ sequences in Windows(-like?) header files, which would obviously prevent the compiler from processing those header files into its parse tree.

 

As a basic metric, before leaving the conversion to Amine, I converted roughly 10% of the 800 projects in ReactOS to the IDE. The load time was 3 seconds for this 10%, but I had not yet specified the #include paths to the IDE, and hence, the code was not building, and surely, the edit-time compilation was aborting each time that it could not find a #include file, for, say, mminit.c.

 

This leaves us to conclude that the best way to find out what the true performance will be is to finish the structure of the .sln and .vcproj files to their final state, removing superfluous paths and inclusions, and measure that.

 

Finally, all of this is only for x86-32. There is still x86-64, and ARM to consider. Fortunately, Visual Studio knows better than to build IntelliSense databases for all CPU’s simultaneously. When the user tells the IDE to use a particular CPU, that is when Visual Studio starts is computation of the IntelliSense parse-tree.

 

-John

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of BinSys
Sent: Thursday, January 10, 2013 11:48 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

I suggest a sln file in each directory. Only a sln file is too big, very slow to load.

At 2013-01-11 07:01:28,"J. C. Jones" <jaibuduvin@gmail.com> wrote:

Hi All,

I wanted to give an update since it has been a few days.

 

As you know, Amine was already in the process of generating Visual Studio .sln and .vcxproj files for the entire ReactOS tree when I started my own parallel conversion to Visual Studio. Therefore, I dropped my own conversion, since there would have been considerable redundancy had I not. Here is what there is so far (Amine can correct me if I am wrong):

1.       Developer pulls entire ReactOS source tree from SVN repository.

2.       Developer pulls CMake bundle from ReactOS.org

3.       Developer includes in ENVIRONMENT variable the path to Cmake bin directory.

4.       Developer executes cmake –version.

5.       Developer executes configure VSSolution.

6.       Developer opens host-tools\reactos.sln and compiles it.

7.       Developer opens reactos\reactos.sln and does build.

 

I am sure Amine can tell you more if you like.

-John

 

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Ged Murphy
Sent: Sunday, January 06, 2013 6:11 AM
To: ReactOS List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

To speed up the process for you, I'd recommend you get a copy of RosBE and run 'make msvc10'

This will generate all the project files and a solution for for you, in a mostly buildable state. I think it may also generate some property sheets, which you should definitely try to incorporate. I can help you with suitable property sheets if you'd like some advise on this.

 

We've already put quite a bit of effort into generating dynamic visual studio projects, (as this is definitely the only maintainable solution IMO), so the outputted vcxproj files should lay down a good base for you to work with. 

 

Ged.

 

 

From: "J. C. Jones" <jaibuduvin@gmail.com>
Reply-To: ReactOS List <ros-dev@reactos.org>
Date: Friday, 4 January 2013 19:30
To: ReactOS List <ros-dev@reactos.org>
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

Ok. VS2010+ it will be. J

 

I will do a quick review to make sure that we can get all the multiple-CPU development features, etc. and report back.

 

Cheers.

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin
Sent: Friday, January 04, 2013 1:25 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

It's up to you of course, but VS2008 is too dated, and VS2012 is "too new" indeed, so many devs will cry about incompatible project files.
So, VS2010 would be the ideal bet, as Ged said.

Regards,
Alex Bragin

On 04.01.2013 23:21, J. C. Jones wrote:

Yes.

 

But initially, I wanted to make it so that anyone, especially a newbie, could go from discovering ReactOS, to an edit-compile-link-debug cycle of “Hello, World!” within the IDE  in 30 minutes or less (not the OS, just a single app). That means accommodating whatever version of Visual Studio they are using. VS2008 is safe, because, no matter which version they are using: VS2008, VS2010, VS2011, or VS2012, the conversion would be done automatically, on their machine, and since the project files in SVN would be locked, there’d be no harm done to SVN using this method. However, if I start out with VS2012, for example, then, sure, they could go and download VS2012 alongside say, VS2010…but my goal was to present a totally new user with the SVN URL for ReactOS, and say, “Here is is. Give it a try!”, and remove all excuses for them trying it out. [I figured that having to install a 1GB+ tool alongside a very similar tool was a bigger excuse for most newbie developers than having to wait < 5 minutes to watch the VS2012 do its conversion.]

 

That said, if Visual Studio users came back and said, “We’re not using VS2008 anyway!” then I would change it, and I am definitely open to ideas on this.

Sent: Friday, January 04, 2013 3:43 AM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

VS2008?

Shouldn’t you be doing this in 2012, especially considering the much improved support for kernel mode projects.

At the very least you should be using 2010 as 2012 can open 2010 project without modification to project files.

 

 

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of J. C. Jones
Sent: 04 January 2013 02:40
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

Yes, it is one thing to create a project file, which takes 15-30 seconds. It is another thing to get the configuration right.  Fortunately, there are copious notes and highly-readable scripts in the tree which practically say what needs to be done, so I do not anticipate any major hurdles.

 

I spent a little time in the source tree today. I integrated a few modules into Visual  Studio 2008, an tested calc, by buiding it from within Visual Studio for x86-32 and x86-64. It ran fine, thanks to the author(Mr. Carlo Bramini) who left good notes in his source code. Just for kicks, I also created an ARM-based project that would run on the Raspberry Pi, compiled it from within  VS2008, and ran it inside the emulator that comes with VS2008. That ran fine also. Tomorrow I will ask a colleague to try the following:

1.       Pull the repository to his local hard disk from inside Visual Studio.

2.       Hit Build.

3.       Run calc in an edit- compile-debug loop.

 

 

From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer
Sent: Thursday, January 03, 2013 2:18 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Notice Of Intent - Visual Studio Build of ReactOS

 

Am 02.01.2013 19:04, schrieb J. C. Jones:

It would take 2-3 hours to create VS projects for all user-mode modules.

No offence, but I think you are highly underestimating the magnitude of our codebase. We are talking about several hundred modules. And you probably also overestimate the pace at which you can create project files. I did that myself for a much smaller project, so I know what I'm talking about.
But maybe I'm wrong and they call you "The Machine" :D


 

 


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/6008 - Release Date: 01/03/13

_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/6012 - Release Date: 01/05/13


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2637/6023 - Release Date: 01/10/13


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2890 / Virus Database: 2637/6025 - Release Date: 01/11/13