Re: Any tips?
On Thursday, 14 March 2013 22:36:16 UTC, Balog Pal wrote:
On 3/14/2013 6:34 PM, James Kanze wrote:
[...]
There are so many things that one can easily do in
makefiles, but which are extremely complicated, if not
impossible, with MS's project and solution files (which is
what the IDE uses). Some examples of things you cannot do
in a Microsoft project:
- Build a local .exe to generate the code you need to compile
for the .dll the project is supposed to build. You have to
create a separate project for the .exe (even if it is build from
only a single .cpp). Which, of course, exposes an internal
detail of the project to everyone working on the solution.
You just described how to solve the *build*. So it is not impossible,
right? All tools normally impose some way of organization. So you youse
two projects instead of one. Actually I can think of several ways to
work it around, but all look way too much hassle with an excessive
requirement (and one pretty moot with original comparison).
Adding projects right and left breaks encapsulation.
- Use the same project in different solutions, with the
solution passing down information telling the project how to
configure itself. You can work around this somewhat, by using
conditionals in the project file, but it's awkward, since the
support for conditionals only supports full equality.
Well, it's indeed an overlook that you can't define macros and params
directly in .sln, but you can define them in several ways. And having a
.props file with the condition on solution name and defining them seem
not such a big difference to me.
Yes. Project files seem to lack a few features, but The
solution files are literally from the middle ages.
You
can't make something conditional on a regular expression match
on the solution name, for example.
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). If
some form of regular expressions are supported, Microsoft isn't
documenting the syntax needed to use it. (In other contexts,
I'm sure that Microsoft supports regular expressions, but they
don't seem to provide a syntax for it here.)
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.
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.
Add to this that the VS compiler's error messages can be totally
useless when templates are involved. Not always, not even
usually, but from time to time, you'll get an error message
without the slightest indication of where the error is in *your*
sources.
Yeah, that is plain pure PITA and shame on MS folks. Actually templates
are the better covered part -- but just have an error in a .h file, the
message will not tell how it was included or even which .cpp was being
compiled. (and it's braindead that /showincludes is option that modifies
the project rather than being part of env. Can be worked around somewhat
but still major WTF, especially as would need minimal work on the
implementation.)
The problem with the .h file seems to be fixed in 2012. On the
other hand, VS parallelizes the builds, and error messages from
different projects are mixed in the output. 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.
[...]
And the fact that you can't debug into code which was
compiled elsewhere, even if you have the sources.
You what? You can attach to any process, and if one crashes you're
offered attach JIT. You can load symbols anytime and anywhere from
remote servers or collect them in your cache, or just ad hoc -- if you
have them certainly. (did you try right-click on gray lines in stack
trace and use Load symbols'?
This seems to be a regression in 2012; I do remember doing
something like what you describe in the past. But when I do
step into function on a Python function, it still steps over.
Without symbols you're really limited to assy, but it may still be
better than nothing.
It is. Even in g++, you can't get full symbolic debugging
without all of the symbols. But if you're familiar with the
compiler and the assembler, you can sort of match things up, and
see what's happening. (I'm not trying to debug Python. I'm
just trying to figure out where it's deciding that my input was
wrong.)
And IIRC you can force to use source file even if
it is not the same as during compile at your own risk.
With 2012, you have to. If there is a pre-build step, the
debugger always decides that the library isn't up to date.
(This definitely wasn't a problem in earlier versions.)
Certainly you CAN and definitely should share most rules -- that is done
by creating .props and .targets files, and the .vcxproj should have only
the file lists. Certainly any really specific options can be set (either
per project or per file).
Certainly. That's what we do, and I've written Python scripts
to generate new projects, to ensure that every one stays on the
same page. (There are a few things, normally at the top, which
don't seem to work if you put them in at .props: the list of
project configurations, for example.
I didn't have to mess with that part. IMO configuration should work if
you import the props early enough, but the IDE would likely not
recognize them. (It looks for some labels to decypher stuff and if you
stray from what it expects, it misreports some elements -- but they
still fork fine in the build.)
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.
(There's another wierd thing in 2012: my pre-build step will
write the output to second file, the delete the original and
rename the second---not really necessary in this case, but old
habits die hard. Rather often, when I do this, VS looses the
generated file. The name still appears in the navigation pane,
but clicking on it gets you nowhere, and if there's an error in
the generated code, clicking on it is also does nothing. This
is definitely a regression; I never had any problems with this
in earlier versions.)
Which was a pain when
I had to add support for 64 bits, but that's not something you
do every day.)
My observation is also that configurations are PITA -- and if you try to
mix C# with C++ in a solution it goes out of hand. Fortunately I could
weed out everything and just have a Debug and Release from the initial
mess. It's especially "nice" how solution creates a full matrix of
config and target.
Do I guess right that you tried to sidestep the mess by creating a copy
of the .sln and one use 32 and the other for 64 bit? I'd probably try
something like that.
No, we have one .sln for both. I actually works pretty well,
but there were a few painful moments getting there.
But the problem remains: you cannot directly
push down information from the solution file (which in addition
uses GUIDs everywhere, rather than the names of anything, which
makes editing it by hand a real pain). Our .props files are
full of things like:
<attribute_name Condition=" '$(SolutionName)' == 'OneSolution' ">value</attribute_name>
<attribute_name Condition=" '$(SolutionName)' == 'DifferentSolution' ">different_value</attribute_name>
...
Every time we use the project in a new solution, we have to come
back and add it here.
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.
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).
--
James