[Qt-interest] which build tools to use?

[Gordon Schumacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Pau Garcia i Quiles wrote:
> macro() just does a text replacement, it'd be like a #define in C
>
> function() is a true function call, i. e. it jumps to other section of code

But the critical piece is the difference in variable scoping -
something that the CMake docs in general discuss only in brief
passing.  It took me a bit to figure out that in order to actually
affect the passed-in return variable name that I needed to do "set
(var value PARENT_SCOPE)".

>         ExternalProject_Add(<name>    # Name for custom target
>            [DEPENDS projects...]       # Targets on which the project
depends
>            [PREFIX dir]                # Root dir for entire project
>            [LIST_SEPARATOR sep]        # Sep to be replaced by ; in cmd
lines
>            [TMP_DIR dir]               # Directory to store temporary files
>            [STAMP_DIR dir]             # Directory to store step timestamps

Okay, but first, how/why do I actually *use* those options?  With
several of them, it's pretty much left to "suck it and see" - try
something, have it not work, so try something else.  And as for my
question about building from an already existing local directory...
according to the test case code for ExternalProject, you need to use
the URL parameter, not the SOURCE_DIR parameter.  I still haven't the
foggiest clue what the heck SOURCE_DIR is for, if it's not to specify
the directory where the source lives.  :-S

> Do you mean two builds as in Qt 4.4 and Qt 4.5? Or two builds as in Qt
> 4.6.0 release vs Qt 4.6.0 debug?

More like the former - but really in my case, I need 4.x static and
4.x shared.  (In fact, the static build is not only static, it's also
heavily trimmed-down via qconfig.)

> You cannot do either of that easily[*].

I found that out :)

> Can you do that with qmake? Visual C++? (I'd say it's not possible)

VC++ falls in the same category as nmake or GNU make, in that it's a
stone-stupid tool - it has no intelligence about detecting system or
library configuration, so you can do anything you want.  As for qmake,
it's pretty darn limited in what it can do outside a strictly-Qt box -
it doesn't really attempt to "find" packages and such... so on one
hand, you're back at shouldering that responsibility yourself, but on
the other hand, once you've found what you need (i.e., another version
of qmake) you can just call out to it with system() and you're done.

CMake is smarter and more powerful - but in my case that works against
me, since it's smart enough to do detect-and-configure, but not smart
enough to be able to override settings for a single subproject.

> Further, what's the point of
> that? If you have two projects which need to be built against two
> different Qt builds, you should have two separate projects with two
> separate build directories.

That's good theory, but these are *sub*projects of the same product.
The build looks something like this:

 32-bit Win apps \
                  +-- Assemble installer \
 64-bit Win apps /                        \
                              Linux apps --+--- Assemble ISO
Bootsplash (static) \                     /
                     +-- Assemble initrd /
      Isolinux menu /


Thus there are four distinct top-level projects involved - Linux with
shared Qt, Linux with static Qt, 32-bit Windows, and 64-bit Windows.
That the two Windows configurations and the Linux configuration are
top-level projects makes easy sense to me - they're completely
separate toolchains.  That Linux is split in half seems very strange
to me... and the work I had to go through to make that possible was
pretty extreme.

>
> [*] You can if you "reset" the Qt-related variables in the
> CMakeLists.txt in project B:

Actually, I am pretty sure that won't work - I tried several
variations of that first.  Since the relevant variables are stored in
the cache, if you reset them, then they stay reset for other projects
in the tree.

> To propagate variables, use set( ... PARENT_SCOPE ). Again:

Not propagate *up* - propagate *down*.

The only way I managed to make it work was, indeed, by making it a
separate project tree, hand-stuffing the variables which I needed to
propagate downward into the subproject's CMakeCache.txt, calling CMake
on the subproject, and adding a custom build target for the subproject
to call "cmake --build" on it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAksakDEACgkQ2yRp4mXKHF2eYwCfWwGeRNemcS4w594wHKv8km2o
id4AoK3a1OWJsG60huPAfdWmzr7y0QCD
=VQHq
-----END PGP SIGNATURE-----