On Tue, Jan 29, 2013 at 09:26:28 +0100, Andrew Wagner wrote:
> On Tue, Jan 29, 2013 at 6:38 AM, <
ad...@computerquip.com> wrote:
> > 3. Macros aren't very useful outside of reducing redundancy.
> > I would like to be able to assign to a variable and as such, use macros
> > within macros, or next to other macros.
> > Why am I still having to manually insert a "-I" before every include folder?
> > Isn't this a sort of redundancy itself (and error prone)? Can't this be
> > avoided through tup?
>
> One of the reasons I personally find CMake infuriating to use is that
> every little trivial thing is hidden behind macros. That's how they
> achieve handling of all the little stupid platform dependent special
> cases, but the cost is that many (I would say most) CMake users have
> no idea what is going on under the hood and they just resort to trial
> and error until things work.
Telling CMake to generate verbose Makefiles usually helps this problem
(or just doing make VERBOSE=1) to see what CMake thought you meant. Yes,
lots of platforms have silly little incompatabilities, but CMake also
supports quite a wide range of tools (from Sun's compiler to AIX
machines to MSVC) without the developer needing to know that rpath
support on platform X with compiler Y needs flags A, B, and C while Z
just needs D. For a fairly large project, the only platform-dependent
things I have in the build system are:
- some install path differences between Windows and not Windows;
- a section for adding some GCC flags versus MSVC flags;
- setting the extension for Python libraries to pyd on Windows (rather
than ${CMAKE_SHARED_MODULE_SUFFIX});
- path list separator characters (';' versus ':') (and configured
headers used to get the default paths for Windows because ';' is not
valid on the command line...even in "/DFOO=bar;baz"); and
- telling Boost to not do its auto-linking on Windows.
I don't need to care that MSVC uses /D rather than -D for defines, that
Windows needs .lib and .dll files generated for libraries, that *nix
platforms like to have a soversion while Windows does not, that the
build tree works best with rpaths in the libraries (but they should be
stripped when installed), and executing a process during the configure
stage (to extract git hashes, determine where NumPy is installed and its
headers live, etc.) is the same on Windows and other platforms.
I admit that CMake isn't perfect, but the things that it does for its
users in the face of obscure platforms is fairly substantial. Not to
mention that I can make the people who use Visual Studio happy while
being able to not have to touch a single vcxproj file[1].
It's nice that Tup is trying to make the build system cleaner and more
rigorous, but I believe that Tup might do well to try and hide these
ugly differences from the user as much as possible. The real world is
not pretty, especially when the goal of "cross platform" is involved
(which is fairly important in build systems).
--Ben
[1]I tend to use cmake --build on Windows, so I don't use VS more than I
need to check that things look as they should there (such as the list of
targets, that the target names aren't too long, and other issues that
have cropped up).