Re: Any tips?
On Wednesday, March 13, 2013 8:31:48 PM UTC, Balog Pal wrote:
On 3/13/2013 4:55 PM, James Kanze wrote:
For production code, of course, the fact that you can't really
create arbitrary rules, like you can in a makefile, is
a problem. As is sharing "projects" between different
solutions, which use different compiler options. I've done it,
but it involves editing the project files by hand; at that
point, you're better off using makefiles, because the higher
level makefile can pass explicit information down to the project
file. (With VC++, you have to create rules conditioned on the
solution name.)
I wonder where this comes -- MS switched to MsBuild a few years ago, and
in that you can do about anything you could in a makefile. Yes, those
who mastered makefiles already may be better off with that. Others are
probably not, as for the sensible stuff it's ways simpler, and plays
naturally with the IDE.
That's simply not true. 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.
- 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. You
can't make something conditional on a regular expression match
on the solution name, for example. And conditions on the
solution name are the only way you can make anything dependent
on the actual solution file.
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. And the fact that you can't debug into code which was
compiled elsewhere, even if you have the sources. (I've
recently worked on a Python interface, and at times, it was
useful to step into the Python code, to see what Python was
expecting of me, and what I was doing wrong. The VS debugger
simply refused to do it; luckily, I had access to Linux box as
well, with gdb.)
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. Which was a pain when
I had to add support for 64 bits, but that's not something you
do every day.) 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.
So all you write about is possible alright. I don't say it is trivial or
nice but that same applies to make and probably most other build systems
for big real-life projects.
It's true that most build systems are pretty bad: I've been
using GNU make, largely because I know it, but the make syntax
is horrible. Of the other systems I've tried, however, either
they don't have the support for some feature I need, or they're
simply broken.
The dependency checking in both Jam and VS is seriously broken:
VS fails when pre-build steps modify sources or headers (and
only allows one pre-build step per project, so you have to write
scripts to chain several together), and Jam fails when you use
things like:
#include GB_dependentInclude(syst,dependentSource.cc)
(where, of course, the underlying macros will change the path so
that dependentSource.cc will be found in a system dependent
directory---instead of syst, you could do arch, for architecture
dependent, or comp, for compiler dependent).
Bash syntax is a bit special, but the real problem is that the
individual tools aren't always coherent. You need to learn
several different variations of regular expressions, for
example. It's still an order of magnitude better than Perl, but
I tend to use Python for anything non-trivial today (unless it's
non-trivial enough to justify using C++).
Yeah, me too -- IMO python beats why bother with old scripting stuff
when it provides all the power, is portable and reads like a real
language instead of emulating the old modem output before NO CARRIER. :->
So you've tried Perl as well. :-)
--
James