Home Dashboard Directory Help

When used to create a source file CustomBuild does not run correctly by Bill Hoffman


Status: 

Closed
 as Fixed Help for as Fixed


3
0
Sign in
to vote
Type: Bug
ID: 473709
Opened: 7/10/2009 6:59:51 AM
Access Restriction: Public
1
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I have a project that basically does this:

There is a file:
foo.in # used as input to create foo.pre
foo.pre # created from foo.in, and used to create foo.c
foo.c compiled into a static library. This worked in VS 6,7,8, and 9, but fails in 2010.
Details
Sign in to post a comment.
Posted by Microsoft on 9/24/2009 at 11:28 AM
Hello,

Again, thank you for the detailed information on this. We revisited this bug based on your feedback and a fix will be available in the RC/RTM timeframe. VS2010 will now look at inputs and outputs to decide the order in which to execute custom build tools associated with files. Note that this will be specific to files associated with CustomBuild target; dependencies on files handled by other steps in the build will need to be adjusted using MSBuild syntax (BeforeTargets, AfterTargets, DependsOn).

Hope this accommodates yours scenarios. Now that we fixed this, most likely .rules files are not such a compelling option but wanted to clarify a few points:
- custom build rules can be distributed with .vcxproj files. The path to a rule will always be stored as relative to the project. We use the CBR Search Path only for populating the CBR UI with a list of available rules, not for resolving the rules included in a project.
- a rule can be associated with a default extension, such that mainline scenarios like adding a .asm file to the project does not require additional setup if MASM rule is enabled, but they do support the ability to be associated with any files part of the project. If you right click on a file and bring up the property pages, from the Item Type you can override the default with not only the built-in tools but also with a custom build rule.
- rules were first added in VS2005 so there is no VC6 equivalent, but they were meant to be a much more flexible way of incorporating 3rd party tools in the build process than Custom Build Steps/Tools/Build Events.

Thanks for trying out VS2010 and for your feedback. Don't hesitate to send us any other feedback you have about the product.
Marian Luparu
Visual C++ Project & Build
Posted by Bill Hoffman on 8/4/2009 at 11:44 AM
The .rule files are not a good substitute for this. The .rule file has to be installed into VS IDE, and does not seem to be distributable with the .vcproj file. There does not seem to be a way to associate a .rule file with a .vcproj, you have to "install" the rule file by using the IDE GUI. This is really not an acceptable way of defining rules. Also the .rule files depend on file extensions. It was possible in the old way to define rules that were for a specific file. For example, you could have foo.in -> createfoo1, and bar.in -> createbar. Same extension two different commands being run. I don't think the .rule is really the right way to do what we want to do, and what has been supported since VS 6.
Posted by Bill Hoffman on 7/31/2009 at 6:45 AM
One more note, this might break lots of projects. It has been working in all previous versions of VS as expected 2010 is the first to not do this in the right order. I am guessing it was not by accident that it worked so well in all those previous versions of Visual Studio, it must have been implemented to work that way.
Posted by Bill Hoffman on 7/31/2009 at 6:40 AM
This should be documented. Why does the custombuild have input files and output files if they are ignored? I create a custombuild that outputs foo.pre, and one that has an input of foo.pre shouldn't all inputs be generated before running the custombuild. What is the point of listing inputs and outputs if they are ignored?

The current docs seem to support my position:

http://msdn.microsoft.com/en-us/library/hefydhhy(VS.80).aspx

Input dependencies can also ensure that your custom build steps run in the order you need them to. In the preceding example, suppose that MyHeader.h is actually the output of a custom build step. Because MyHeader.h is a dependency of MyInput.x, the build system will first build Myheader.h before running the custom build step on MyInput.x.

The name of the output file should be what is specified in the Command Line property. The project build system will look for the file and check its date. If the file is newer than the input file or if the file is not found, then the custom build step will run. If all of the Additional Dependencies files are older than the input file, and the input file is older than the Outputs file, then the custom build step will not run.



Posted by Microsoft on 7/30/2009 at 5:57 PM
Hello,

Thank you for your report. In your report, one file in the CustomBuild item group has a dependency on another file inside the same itemgroup. This is not supported as there is no guarantee made on the order in which the files in the CustomBuild will be executed during build. This issue is By Design.

If you want more flexibility to define when in your build a command should run, please use Custom Build Rules. They allow you to explictly specify when in the build the rule specific command line should be executed. On how to create Custom Build Rules in VS2005 and VS2008 please review http://msdn.microsoft.com/en-us/library/aa730877(VS.80).aspx. Documentation for VS2010 Beta 1 on Custom Build Rules is not yet available but you can follow http://blogs.msdn.com/vsproject and http://blogs.msdn.com/vcblog for upcoming posts on this.

Thanks,
Marian Luparu
Visual C++ Project & Build
Posted by Microsoft on 7/14/2009 at 11:57 PM
Thanks for your feedback.

We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by wva on 7/13/2009 at 7:09 PM
Please fix. We want CMake to work smoothly with VS2010:)
Posted by Microsoft on 7/13/2009 at 4:44 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by brad.king on 9/7/2009 at 7:19 AM
Dependent CustomBuild steps seem work if they are in separate ItemGroup elements *and* the groups are sorted in topological order (with dependees coming before their dependers). MSBuild seems to evaluate the AdditionalInputs/Outputs only with respect to file timestamps and does not use them to order evaluation of rules; instead only the order of appearance across ItemGroups determines the order of evaluation. If anyone knows of MSBuild documentation that supports this observation, please post a link.