[opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Jan 5, 2017 at 8:52 PM, Nicky Perian <nickyperian at gmail.com> wrote:

I was expecting to build from the windows command prompt. I can go into
> Cygwin64 terminal and
> eval "$(autobuild source_environment)" appears to run, but doesn't
> feedback any information that it has.
>

Running that command performs a bunch of bash variable assignments and
'export' commands. It should result in an enriched environment, but you're
right, the command itself doesn't produce output -- unless the bash switch
'set -x' (shell tracing) is in effect.


> I find it disturbing, to say the least, that the total autobuild cannot be
> completed from the windows command prompt.
>

Sigh, I'm afraid my reply was off-base. I was looking at the way you were
manually executing autobuild source_environment, which could only have the
effect of producing output to stdout -- in this case, to your log file.

But the fact is that current autobuild 1.1's configure and build commands
internally execute the equivalent of autobuild source_environment to
produce the environment passed to the relevant commands specified in
autobuild.xml.

So *if you want the parent shell script* to see the variables produced by
autobuild source_environment, you must use either the 'eval' construct or
redirect source_environment output to a file and then 'source' that file,
as shown in a previous message.

But 'autobuild configure' and 'autobuild build' will now internally run
'autobuild source_environment' for their own processing. So if you don't
need to see autobuild source_environment variables in the parent shell, you
can skip explicitly running 'autobuild source_environment' altogether.

Digression:
https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default&fileviewer=file-view-default
sets variables of the form LL_BUILD_WINDOWS_RELEASE, etc. for DARWIN and
LINUX and RELWITHDEBINFO. Since autobuild source_environment knows the
current platform, it also emits an abbreviated variable LL_BUILD_RELEASE
with the same value as LL_BUILD_WINDOWS_RELEASE (or whichever platform).
Given the configuration you want to build, it also emits another
abbreviated variable LL_BUILD with the same value as LL_BUILD_RELEASE (or
whichever configuration). You can see this when you run 'autobuild
source_environment -c Release' with AUTOBUILD_VARIABLES_FILE set in your
environment.

What should happen is that autobuild configure will internally run
'autobuild source_environment' for the current platform and build
configuration. Thus the CMake logic specified in the viewer's
autobuild.xml, invoked by 'autobuild configure', should (!) see a non-empty
LL_BUILD variable... if AUTOBUILD_VARIABLES_FILE is visible in the
environment passed to autobuild configure.

When the platform-and-config-appropriate LL_BUILD value (containing e.g.
-DLL_WINDOWS) is passed to the viewer's CMake machinery, CMake will in turn
pass those command-line switches to the compiler:
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/cmake/00-Common.cmake?at=default&fileviewer=file-view-default#00-Common.cmake-21

When indra/llcommon/llpreprocessor.h sees (e.g.) LL_WINDOWS, it #defines
LL_TYPEOF():
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llpreprocessor.h?fileviewer=file-view-default#llpreprocessor.h-195

And it was lack of LL_TYPEOF() that was causing those baffling "unexpected
type 'S'" errors in llunittype.h:
https://bitbucket.org/lindenlab/viewer64/src/tip/indra/llcommon/llunittype.h?fileviewer=file-view-default#llunittype.h-47

If you are still seeing those errors, you might try adding message output
to indra/cmake/00-Common.cmake, something like:

MESSAGE(STATUS "AUTOBUILD_VARIABLES_FILE =
'$ENV{AUTOBUILD_VARIABLES_FILE}'")
MESSAGE(STATUS "LL_BUILD_WINDOWS_RELEASE =
'$ENV{LL_BUILD_WINDOWS_RELEASE}'")
MESSAGE(STATUS "LL_BUILD_RELEASE = '$ENV{LL_BUILD_RELEASE}'")
MESSAGE(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")

Of course, if you're trying to build RelWithDebInfo instead of Release, try
reporting LL_BUILD_WINDOWS_RELWITHDEBINFO and LL_BUILD_RELWITHDEBINFO
instead of (or as well as) the output above.

Sorry for not explaining this more fully yesterday!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170106/855aca9d/attachment.html