Re: Any tips?
On 3/15/2013 6:18 PM, James Kanze wrote:
I'm not so proficient in msbuild to provide actual counterexample code
but am 99% positive that claim is false. You can use a wide range of
string manipulation and other functions -- I do in practice. [it was a
year ago when I had to fix the build of or project]. I recall i could
use anything you can do with a C# String.
I'm basing my statement on the reference
(http://msdn.microsoft.com/en-us/library/7szfhaft.aspx).
That is certainly true, but only half of it. The condition itself is
only == but you can use expressions with lhs and rhs.
If
some form of regular expressions are supported, Microsoft isn't
documenting the syntax needed to use it.
Just try the expressions I referred to in previous post. I definitely
used them in my common .props -- could post example from a different
machine only.
And conditions on the
solution name are the only way you can make anything dependent
on the actual solution file.
I bet in practice you use the project in just a handful of solutions and
can figure out groups with just basic string ops if regex is really not
accessible -- what may well be.
In practice, I have no idea what solution files are being used.
Well, I see your case from the other branch -- indeed it has some
challenges.
I deliver library components, which other groups merge into
their final product. I can't make an exhaustive list of all
solutions, because I don't even know all of my clients.
I recall two approaches for such situations. One compiles the component
in several versions, distribute the binaries (that have suffixes for
versions) and .h, the latter has magic to figure out the proper variant
and sets it as defaultlib.
The other is to compile from source -- with that it is natural
expectation to follow all the prescribed steps to add the project or
project group.
And here it's possible to map configs in the build manager -- the
solution has the usual 2 (debug/release), and for your project selects
the desired variant of the 8).
The problem with the .h file seems to be fixed in 2012.
Wow at least some progress in a decade.
On the
other hand, VS parallelizes the builds, and error messages from
different projects are mixed in the output.
You have Build and Build order variant for the output window. (in
regular workflow it's rarely needed, enter a failed build I hit the
"build-project only" variant immediately.
For the moment, if
I can't find the error quickly, I'll copy paste the entire
output pane into vim, then run a Python script
(SortOutputByProject.py) over it, then search for error. Once
I know which project isn't building correctly, I can build only
it, and get some usable error output.
The project itself is properly noted in the 'error list' that should be
the primary source of navigation, output is only for the weird cases.
There's a convenient option to auto-switch error list on errors too.
It only seems to be an issue when you create new projects.
Except for VS completely rewriting your filter files whenever
you add or remove a file.
It rewrites everything. Fortunately Git Extensions provide convenient
way to reset unintended lines from change or post-edit the file.
If you use some naming schema that fits with the available string
functions you can make it much simpler. I'd put .EndsWith("64") or
.IndexOf to locate substrings. That IMO could save most of the edits in
a practical system.
We do. The problem is that the conditionals only support ==, !=
and HasTrailingSlash for strings.
Do you say '$(solutionname).Endswith("64")' == 'true' does not work?
But even with the raw form,
compared to all the crap I face everyday I would not consider to mention
that as a minor nuisance. Yes, you have to configure the stuff somewhere
-- so have one file that maps solution names to a set of attribute
values, and the projects work with the latter. And include the mapper up
front.
Sure in my practice there's no proliferation of .sln files, others may
not be so fortunate.
http://msdn.microsoft.com/en-us/library/dd633440.aspx
This seems to apply to the MSBuild framework, and not to the
project files; at least, it talks of tasks, which aren't present
in the .vcxproj files (at least not that I've seen).
The vcxproj file is just a top level thing that includes the real
content from other .props and .targets files. You probably should read
the Microsoft.Cpp.targets to see how the build is arranged (including
details of prebuild step), then add your own .targets that define your
code generator in the native way, dropping prebuild madness for good.