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.
[reordered...]
Do you say '$(solutionname).Endswith("64")' == 'true' does not work?
Brilliant. That is exactly what I was looking for. In
practice, I have two known variants I have to support, one of
whose solution files always ends with a common string. (There's
still the third party library issues, but generally, they should
be using the other variant—there is one which even uses
a completely different version of Visual Studios, but they
accept that they're on their own there, and I do document what
I've done, so that they can duplicate the effects if they need
them) So basically, I'll end up with something like:
<MyAttribute Condition="'$(solutionname).Endswith("ABC")' == 'true'>for IFG</MyAttribute>
<MyAttribute Condition="'$(MyAttribute)' == ''>not for IFG</MyAttribute>
(The set of solutions whose name ends with "ABC" is open, and
has been added to more than once. This used to be a pain, but
I think you've given me the solution. A thousand thanks.)
[...]
Well, I see your case from the other branch -- indeed it has some
challenges.
Yes. What I can do, sort of, however, is impose naming
conventions and suggest default configurations (which we know
work). Beyond that... different groups who want to do just
anything are sort of on their own anyway. We can't test that
the code works in a configuration we've never heard about.
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.
Our solution has been for the clients to integrat our library
into their solution files, and compile from source. I don't
really agree with this—I think it would make sense to
establish a company wide policy with regards to what variants we
support, and how we deliver them (generally in a separate
directory for the DLLs, and of course, the headers are
independent of this). But for various reasons, this doesn't fly
politically.
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).
We are actually moving to supporting thre configurations. It
turns out that when you have iterator debugging active, some of
parts of the library are so slow that you cannot effectively
debug with real data sets. (You can't debug if it takes you four
hours to reach a breakpoint.) So our debug builds have iterator
debugging disactivated (which in turn means that until VS 2010,
we couldn't use std::string). Still, we've seen more than a few
problems which would have been caught immediatly by iterator
debugging. (Including one case where end() was dereferenced,
which caused one, and only one machine to give wrong results.)
So we want two different Debug configurations, one for tracking
down errors that only show up with real data, and another with
iterator debugging (which hopefully will cause most such cases
to show up in our test suite).
[...]
It rewrites everything. Fortunately Git Extensions provide convenient
way to reset unintended lines from change or post-edit the file.
We're not using git, but I would like to see a Subversion plugin
used to rewrite the filter file. (It's easy to do---just throw
out all of the ItemGroup except the first.)
[...]
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.
I'm aware of the .props. I'll have to look into the .targets.
Maybe that's the answer.
And thanks again for the tip with regards to how to use the
expressions in a conditional. That's already made my life
significantly simpler.
Actually with the msbuild-based way it's