Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Tue, Feb 21, 2017 at 9:36 AM, Nicky Perian  wrote:

>>The autobuild feature that implicitly expands environment variables such
> as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent,
> and we probably haven't yet covered all the cases where that >>should
> happen.
>
> As far as i can tell this happens only on 32 bit builds.
>

Um. That's somewhat surprising, as I would expect that either we always
fail to expand $AUTOBUILD_ADDRSIZE regardless of the value of that
variable, or we always expand $AUTOBUILD_ADDRSIZE regardless of the value
of that variable.

But any specific use case -- "With this specific autobuild.xml and this
version of autobuild, I issued this specific autobuild command and got the
following result" -- would be helpful in diagnosing the problem. In fact,
if it goes into a Jira instead of this email thread, it's less likely to
get lost.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>>The autobuild feature that implicitly expands environment variables such
as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent,
and we probably haven't yet covered all the cases where that >>should
happen.

As far as i can tell this happens only on 32 bit builds.


On Sat, Feb 18, 2017 at 3:11 PM, Nat Goodspeed  wrote:

> On Feb 18, 2017 1:33 PM, "Nicky Perian"  wrote:
>
> Any idea why autobuild the looks in the wrong location for
> installed-packages.xml?
>
> == Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped
> ==
> metadata file name: autobuild-package.xml
> built Second Life Viewer version 5.1.0.41141
> installed files in installed-packages.xml
> no installed files found (C:\Users\Bill\P64\Kokua-SL-64
> \build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)
>
>
> The autobuild feature that implicitly expands environment variables such
> as $AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and
> we probably haven't yet covered all the cases where that should happen.
>
> The initial implementation expanded variables right at the point when
> autobuild.xml is read, so the expansions applied EVERYWHERE. That turned
> out to be the wrong approach, since a number of autobuild commands rewrite
> autobuild.xml. We found, to our dismay, that after any such command, all
> the variables had been replaced with the specific value at that moment -
> making the parameterization useless.
>
> So now we expand variables in specific subcommands. I'm sure we don't yet
> do that everywhere we should.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Feb 18, 2017 1:33 PM, "Nicky Perian"  wrote:

Any idea why autobuild the looks in the wrong location for
installed-packages.xml?

== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ==
metadata file name: autobuild-package.xml
built Second Life Viewer version 5.1.0.41141
installed files in installed-packages.xml
no installed files found (C:\Users\Bill\P64\Kokua-SL-
64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)


The autobuild feature that implicitly expands environment variables such as
$AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and we
probably haven't yet covered all the cases where that should happen.

The initial implementation expanded variables right at the point when
autobuild.xml is read, so the expansions applied EVERYWHERE. That turned
out to be the wrong approach, since a number of autobuild commands rewrite
autobuild.xml. We found, to our dismay, that after any such command, all
the variables had been replaced with the specific value at that moment -
making the parameterization useless.

So now we expand variables in specific subcommands. I'm sure we don't yet
do that everywhere we should.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Any idea why autobuild the looks in the wrong location for
installed-packages.xml?

== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ==
metadata file name: autobuild-package.xml
built Second Life Viewer version 5.1.0.41141
installed files in installed-packages.xml
no installed files found
(C:\Users\Bill\P64\Kokua-SL-64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml)

On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian  wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (or -A 64) for the autobuild uninstall command to >>select the correct
> build directory.
>
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
> uninstall openjpeg
> usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
>  [-A {32,64}]
>  {} ...
> autobuild: error: invalid choice: 'uninstall' (choose from )
>
> and more ...
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
> --address-size 32 openjpeg
> Traceback (most recent call last):
>   File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
> line 11, in 
> load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 263, in main
> sys.exit(Autobuild().main(sys.argv[1:]))
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 250, in main
> tool_to_run.run(args)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 151, in run
> uninstall_packages(args, installed_filename, args.package,
> args.dry_run)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
> installed_file.save()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
> line 366, in save
> file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
> representation))
> IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
> SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'
>
> On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed  wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian 
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Sat, Jan 28, 2017 at 10:00 PM, Nicky Perian 
wrote:

macOS build ?
> Am I missing something? I have tried ReleaseOS command line build and
> cmake doesn't change to the correct source directory to complete the test
> compile.
>
> Are macOS command line builds possible at this time?
>

I think what you're encountering is that there is no longer a 'darwin'
platform in viewer64/autobuild.xml, only 'darwin64'. If you use 'autobuild
configure -A 64' (or leave AUTOBUILD_ADDRSIZE=64 set in your environment)
it should work.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

macOS build ?
Am I missing something? I have tried ReleaseOS command line build and cmake
doesn't change to the correct source directory to complete the test compile.

Are macOS command line builds possible at this time?

On Fri, Jan 20, 2017 at 9:55 AM, Nat Goodspeed  wrote:

> On Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian 
> wrote:
>
> Moving on to Linux and Linux64.
>>
>
> Now you're breaking trail. For the present, we're focusing on Windows and
> Mac.
>
>
>> I noticed there isn't an archive for 3p-mesa for linux64.
>> The one I have used for building linux64 on Kokua is very old.
>>  http://s3.amazonaws.com/viewer-source-downloads/install_
>> pkgs/mesa-6.2.1-linux64-20081016.tar.bz2
>>
>> Will this be updated for P64_3p-mesa?
>>
>
> Let's talk about plans for Linux at the TPV meeting next week.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Fri, Jan 20, 2017 at 8:53 AM, Nicky Perian  wrote:

Moving on to Linux and Linux64.
>

Now you're breaking trail. For the present, we're focusing on Windows and
Mac.


> I noticed there isn't an archive for 3p-mesa for linux64.
> The one I have used for building linux64 on Kokua is very old.
>  http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1-
> linux64-20081016.tar.bz2
>
> Will this be updated for P64_3p-mesa?
>

Let's talk about plans for Linux at the TPV meeting next week.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Moving on to Linux and Linux64.

I noticed there isn't an archive for 3p-mesa for linux64.
The one I have used for building linux64 on Kokua is very old.

http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-6.2.1-linux64-20081016.tar.bz2

Will this be updated for P64_3p-mesa?



On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian  wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (or -A 64) for the autobuild uninstall command to >>select the correct
> build directory.
>
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
> uninstall openjpeg
> usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
>  [-A {32,64}]
>  {} ...
> autobuild: error: invalid choice: 'uninstall' (choose from )
>
> and more ...
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
> --address-size 32 openjpeg
> Traceback (most recent call last):
>   File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
> line 11, in 
> load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 263, in main
> sys.exit(Autobuild().main(sys.argv[1:]))
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 250, in main
> tool_to_run.run(args)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 151, in run
> uninstall_packages(args, installed_filename, args.package,
> args.dry_run)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
> installed_file.save()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
> line 366, in save
> file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
> representation))
> IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
> SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'
>
> On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed  wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian 
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Niran]

I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all
that better... it was... unreliable.

2017-01-17 18:09 GMT+01:00 Nicky Perian :

> >>Please forgive me if this should already be on my plate, but I don't
> >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
> >>texture files that are correctly handled by 1.5.0?
>
> Yes.
> openjpeg-1.5.1 has so many textures marked as over-sized and unavailable
> that the viewer is unusable. This came about with viewer64 as the default
> viewer is still on openjpeg-1.4.0.  I had seen the same texture missing
> message once while using Project Alex Ivy viewer and filed a jira on that
> instance at  https://jira.secondlife.com/browse/BUG-41228 . I am making a
> wild guess, but I think there is a possible CDN delivery issue that
> openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU.
>
> I had not known of openjpeg-1.5.0 every being supplied in a viewer or I
> would have certainly looked for it.
>
>
>
>
> On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley 
> wrote:
>
>> We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can
>> put together some patches to get it working.
>>
>> --
>> Cinder Roxley
>> Sent with Airmail
>>
>> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com)
>> wrote:
>>
>> Nat Goodspeed  erian  wrote:
>>
>> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>> >
>> > Please take this in and then provide for the updated archives in the
>> viewer. I also received a report that the missing texture issue is in macOS
>> when using openjpeg-1.5.1.
>>
>> There are admittedly painful aspects to the two-step autobuild
>> mechanism: (1) rebuild the 3p package and (2) update every consumer.
>>
>> However, one of the benefits of that approach is that we can adjust
>> the version of a given 3p package consumed by (e.g.) the viewer
>> without actually having to revert the 3p repository source. We can
>> just change back the package URL specified in the viewer's
>> autobuild.xml.
>>
>> > Or, if the problem with 1.5.1 is easily corrected
>>
>> Please forgive me if this should already be on my plate, but I don't
>> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
>> texture files that are correctly handled by 1.5.0?
>>
>> I think Cinder has a point: if we can move forward with 1.5.1, we should.
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Cinder Roxley]

We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can put 
together some patches to get it working.
 
 
-- 
Cinder Roxley
Sent with Airmail
 

On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com 
 ) wrote:

 
Nat Goodspeed  erian  wrote:

> https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>
> Please take this in and then provide for the updated archives in the viewer. 
> I also received a report that the missing texture issue is in macOS when 
> using openjpeg-1.5.1.

There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.

However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

> Or, if the problem with 1.5.1 is easily corrected

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load

texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Mon, Jan 16, 2017 at 6:47 AM, Nicky Perian  wrote:

> https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>
> Please take this in and then provide for the updated archives in the viewer. 
> I also received a report that the missing texture issue is in macOS when 
> using openjpeg-1.5.1.

There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.

However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

> Or, if the problem with 1.5.1 is easily corrected

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

@Nat
https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2

Please take this in and then provide for the updated archives in the
viewer. I also received a report that the missing texture issue is in macOS
when using openjpeg-1.5.1.

Or, if the problem with 1.5.1 is easily corrected




On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian  wrote:

>
> and more...
> >>You might have to specify "autobuild uninstall --address-size 64 x"
> (or -A 64) for the autobuild uninstall command to >>select the correct
> build directory.
>
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
> uninstall openjpeg
> usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
>  [-A {32,64}]
>  {} ...
> autobuild: error: invalid choice: 'uninstall' (choose from )
>
> and more ...
> (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
> --address-size 32 openjpeg
> Traceback (most recent call last):
>   File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py",
> line 11, in 
> load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 263, in main
> sys.exit(Autobuild().main(sys.argv[1:]))
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
> line 250, in main
> tool_to_run.run(args)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 151, in run
> uninstall_packages(args, installed_filename, args.package,
> args.dry_run)
>   File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\
> autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages
> installed_file.save()
>   File 
> "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
> line 366, in save
> file(self.path, 'wb').write(llsd.format_pretty_xml(dict_
> representation))
> IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua-
> SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'
>
> On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed  wrote:
>
>> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian 
>> wrote:
>>
>> Does "autobuild uninstall x" work for autobuild-1.1?
>>>
>>
>> You might have to specify "autobuild uninstall --address-size 64 x"
>> (or -A 64) for the autobuild uninstall command to select the correct build
>> directory.
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Henri Beauchamp]

On Fri, 13 Jan 2017 21:53:51 -0600, Nicky Perian wrote:

> Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64
> bit is worse.
> Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the
> same viewer with only openjpeg.dll changed.

There are "fixes" that went into OpenJPEG v1.5 and newer, that break
textures in SL (I posted in this list, long ago, about one such issue).
However v1.5 and v2.0 bring security holes fixes and bug fixes.
That's why I integrated the OpenJPEG v1.4 sources to my viewer (in
indra/libopenjpeg/) and patched these sources with all the fixes I
could find in v1.5 and v2.0 repositories and that are not ruining
texture decoding in SL, as well as with a few more security checks
(potential crash bug fixes) by me.

Feel free to grab the Cool VL Viewer's "libopenjpeg" and integrate it
in your own viewer.

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

and more...
>>You might have to specify "autobuild uninstall --address-size 64 x"
(or -A 64) for the autobuild uninstall command to >>select the correct
build directory.

(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32
uninstall openjpeg
usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM]
 [-A {32,64}]
 {} ...
autobuild: error: invalid choice: 'uninstall' (choose from )

and more ...
(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall
--address-size 32 openjpeg
Traceback (most recent call last):
  File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
11, in 
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 151, in run
uninstall_packages(args, installed_filename, args.package, args.dry_run)
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 71, in uninstall_packages
installed_file.save()
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation))
IOError: [Errno 2] No such file or directory:
'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed  wrote:

> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian 
> wrote:
>
> Does "autobuild uninstall x" work for autobuild-1.1?
>>
>
> You might have to specify "autobuild uninstall --address-size 64 x"
> (or -A 64) for the autobuild uninstall command to select the correct build
> directory.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian  wrote:

Does "autobuild uninstall x" work for autobuild-1.1?
>

You might have to specify "autobuild uninstall --address-size 64 x" (or
-A 64) for the autobuild uninstall command to select the correct build
directory.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>>Documentation that it doesn't is of course welcome

(autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall openjpeg
Traceback (most recent call last):
  File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", line
11, in 
load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')()
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 263, in main
sys.exit(Autobuild().main(sys.argv[1:]))
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py",
line 250, in main
tool_to_run.run(args)
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 151, in run
uninstall_packages(args, installed_filename, args.package, args.dry_run)
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_tool_uninstall.py",
line 71, in uninstall_packages
installed_file.save()
  File
"c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py",
line 366, in save
file(self.path, 'wb').write(llsd.format_pretty_xml(dict_representation))
IOError: [Errno 2] No such file or directory:
'C:\\Users\\Bill\\P64\\Kokua-SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml'

On Fri, Jan 13, 2017 at 4:04 PM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

> On 2017-01-13 17:01 , Nicky Perian wrote:
>
> Does "autobuild uninstall x" work for autobuild-1.1?
>
> as far as we know, yes
>
> Documentation that it doesn't is of course welcome
>
>
> --
> OZ LINDEN | Engineering Director, Second Life
> email or hangouts: o...@lindenlab.com | Real Life: Scott Lawrence
> LINDEN LAB | Create Virtual Experiences 
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Does "autobuild uninstall x" work for autobuild-1.1?

On Thu, Jan 12, 2017 at 12:59 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> KDU build here was indistinguishable from the 32bit viewer-release on
> first inspection.
>
> Tried both with full cache and cleaned one.
>
> On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian 
> wrote:
>
>> [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
>> world.  Terrain and most prim textures are grey. Full bright textures and
>> my avatar appear normal. Is this the same with KDU? I haven't a KDU license
>> or I would check myself.
>>
>> On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. 
>> wrote:
>>
>>> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
 #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
 if ("$ENV{LL_BUILD}" STREQUAL "")
   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
 endif ()

 Above allows configure to complete, but I would like a better place or
 better yet some autobuild involvement to set LL_BUILD based to the chosen
 Release, RelWithDebugInfo, Debug build.



>>> Autobuild tries to do this by some machinery in source environment, but
>>> it fails because you use ReleaseOS. I did encounter the same problem just a
>>> few minutes ago
>>> with ReleaseFS and had to edit the file variables in the build-variables
>>> repository.
>>> Once I added a variable for the configuration, LL_BUILD will be set as
>>> desired.
>>>
>>> https://bitbucket.org/NickyD/viewer-build-variables/commits/
>>> cfab877696c6a35af1d80e5d17ea7acfffa6c762
>>>
>>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Callum Prentice (Callum)]

KDU build here was indistinguishable from the 32bit viewer-release on first
inspection.

Tried both with full cache and cleaned one.

On Thu, Jan 12, 2017 at 10:55 AM, Nicky Perian 
wrote:

> [Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
> world.  Terrain and most prim textures are grey. Full bright textures and
> my avatar appear normal. Is this the same with KDU? I haven't a KDU license
> or I would check myself.
>
> On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. 
> wrote:
>
>> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
>>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
>>> if ("$ENV{LL_BUILD}" STREQUAL "")
>>>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
>>> endif ()
>>>
>>> Above allows configure to complete, but I would like a better place or
>>> better yet some autobuild involvement to set LL_BUILD based to the chosen
>>> Release, RelWithDebugInfo, Debug build.
>>>
>>>
>>>
>> Autobuild tries to do this by some machinery in source environment, but
>> it fails because you use ReleaseOS. I did encounter the same problem just a
>> few minutes ago
>> with ReleaseFS and had to edit the file variables in the build-variables
>> repository.
>> Once I added a variable for the configuration, LL_BUILD will be set as
>> desired.
>>
>> https://bitbucket.org/NickyD/viewer-build-variables/commits/
>> cfab877696c6a35af1d80e5d17ea7acfffa6c762
>>
>>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

[Windows] When I log on with viewer64 w/openjpeg I have a mostly grey
world.  Terrain and most prim textures are grey. Full bright textures and
my avatar appear normal. Is this the same with KDU? I haven't a KDU license
or I would check myself.

On Tue, Jan 10, 2017 at 12:30 PM, Nicky D. 
wrote:

> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
>> if ("$ENV{LL_BUILD}" STREQUAL "")
>>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
>> endif ()
>>
>> Above allows configure to complete, but I would like a better place or
>> better yet some autobuild involvement to set LL_BUILD based to the chosen
>> Release, RelWithDebugInfo, Debug build.
>>
>>
>>
> Autobuild tries to do this by some machinery in source environment, but it
> fails because you use ReleaseOS. I did encounter the same problem just a
> few minutes ago
> with ReleaseFS and had to edit the file variables in the build-variables
> repository.
> Once I added a variable for the configuration, LL_BUILD will be set as
> desired.
>
> https://bitbucket.org/NickyD/viewer-build-variables/commits/
> cfab877696c6a35af1d80e5d17ea7acfffa6c762
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

brute force setting of LL_BUILD environment variable.
There may be a better/smarter way, but it appears to work.
# HG changeset patch
# User Nicky Perian 
# Date 1483848353 21600
#  Sat Jan 07 22:05:53 2017 -0600
# Node ID 7b4fb3c48718213d1cd8c1e6c6dca0d50c95d78e
# Parent  390776087c1d7c83f04af629340839fadfdd0735
Brute force set LL_BUILD based on System name and Build type. If it isn't
set error out of configure.

diff -r 390776087c1d -r 7b4fb3c48718 indra/cmake/Variables.cmake
--- a/indra/cmake/Variables.cmake Mon Dec 19 05:11:36 2016 -0600
+++ b/indra/cmake/Variables.cmake Sat Jan 07 22:05:53 2017 -0600
@@ -12,10 +12,37 @@
 # Switches set here and in 00-Common.cmake must agree with
 # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
 # Reading $LL_BUILD is an attempt to directly use those switches.
+if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+  if (CMAKE_BUILD_TYPE MATCHES "Debug")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_DEBUG})
+  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELWITHDEBINFO})
+  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
+  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+  if (CMAKE_BUILD_TYPE MATCHES "Debug")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_DEBUG})
+  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELWITHDEBINFO})
+  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELEASE})
+  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+  if (CMAKE_BUILD_TYPE MATCHES "Debug")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_DEBUG})
+  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELWITHDEBINFO})
+  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
+  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELEASE})
+  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
+endif(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
 if ("$ENV{LL_BUILD}" STREQUAL "")
   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
 endif ()
-
+#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
 # Relative and absolute paths to subtrees.

 if(NOT DEFINED ${CMAKE_CURRENT_LIST_FILE}_INCLUDED)



On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian  wrote:

> Snip Variables.cmake
> # Switches set here and in 00-Common.cmake must agree with
> # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
> # Reading $LL_BUILD is an attempt to directly use those switches.
> #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}'")
> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
> if ("$ENV{LL_BUILD}" STREQUAL "")
>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
> endif ()
>
> Above allows configure to complete, but I would like a better place or
> better yet some autobuild involvement to set LL_BUILD based to the chosen
> Release, RelWithDebugInfo, Debug build.
>
> Next,
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> cl : Command line warning D9002: ignoring unknown option '/OP'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OT'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/O:'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OR'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OE'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OF'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option
> '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\
> build-vc120-64\llcommon\llcommon.vcxproj]
>
> No idea where /O* switches are set but appear to be included in every
> *.vcxproj.
> '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
> LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
> /NODEFAULTLIB:LIBCMT*"
>
> These link switches are set in 00-Common.cmake.
>
> Once removed those warning are no longer listed. 

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

LL list server problem so resending.

On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian  wrote:

> Snip Variables.cmake
> # Switches set here and in 00-Common.cmake must agree with
> # https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
> # Reading $LL_BUILD is an attempt to directly use those switches.
> #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}'")
> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
> if ("$ENV{LL_BUILD}" STREQUAL "")
>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
> endif ()
>
> Above allows configure to complete, but I would like a better place or
> better yet some autobuild involvement to set LL_BUILD based to the chosen
> Release, RelWithDebugInfo, Debug build.
>
> Next,
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> cl : Command line warning D9002: ignoring unknown option '/OP'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OT'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/O:'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OR'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OE'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/OF'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
> cl : Command line warning D9002: ignoring unknown option
> '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\
> build-vc120-64\llcommon\llcommon.vcxproj]
>
> No idea where /O* switches are set but appear to be included in every
> *.vcxproj.
> '/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
> LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
> /NODEFAULTLIB:LIBCMT*"
>
> These link switches are set in 00-Common.cmake.
>
> Once removed those warning are no longer listed. This in likely a case of
> putting link switches in cl without a pass through. I suspect the '/O*'
> switches are link switches also, but grep was of no help finding where they
> are set.
>
> Good news is the build completed without the crazy errors encountered
> earlier.
>
>
>
>
> On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed  wrote:
>
>> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian 
>> wrote:
>>
>> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
>> /DLL_RLEASE_FOR_DOWNLOAD=1
>> >> /DNDEBUG
>> >
>> > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the
>> variable
>> > name changed?
>>
>> Thank you for pointing that out!
>> https://bitbucket.org/lindenlab/viewer-build-variables/
>> commits/a9d6c3061349a14289cffb536320f0aa7bdf472f
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian  wrote:

>>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1
>> /DNDEBUG
>
> DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the variable
> name changed?

Thank you for pointing that out!
https://bitbucket.org/lindenlab/viewer-build-variables/commits/a9d6c3061349a14289cffb536320f0aa7bdf472f
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky D.]

>
> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
> if ("$ENV{LL_BUILD}" STREQUAL "")
>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
> endif ()
>
> Above allows configure to complete, but I would like a better place or
> better yet some autobuild involvement to set LL_BUILD based to the chosen
> Release, RelWithDebugInfo, Debug build.
>
>
>
Autobuild tries to do this by some machinery in source environment, but it
fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.

https://bitbucket.org/NickyD/viewer-build-variables/commits/cfab877696c6a35af1d80e5d17ea7acfffa6c762
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

LL list server issue so resending

On Sat, Jan 7, 2017 at 10:13 PM, Nicky Perian  wrote:

> brute force setting of LL_BUILD environment variable.
> There may be a better/smarter way, but it appears to work.
> # HG changeset patch
> # User Nicky Perian 
> # Date 1483848353 21600
> #  Sat Jan 07 22:05:53 2017 -0600
> # Node ID 7b4fb3c48718213d1cd8c1e6c6dca0d50c95d78e
> # Parent  390776087c1d7c83f04af629340839fadfdd0735
> Brute force set LL_BUILD based on System name and Build type. If it isn't
> set error out of configure.
>
> diff -r 390776087c1d -r 7b4fb3c48718 indra/cmake/Variables.cmake
> --- a/indra/cmake/Variables.cmake Mon Dec 19 05:11:36 2016 -0600
> +++ b/indra/cmake/Variables.cmake Sat Jan 07 22:05:53 2017 -0600
> @@ -12,10 +12,37 @@
>  # Switches set here and in 00-Common.cmake must agree with
>  # https://bitbucket.org/lindenlab/viewer-build-
> variables/src/tip/variables
>  # Reading $LL_BUILD is an attempt to directly use those switches.
> +if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")
> +  if (CMAKE_BUILD_TYPE MATCHES "Debug")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_DEBUG})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELWITHDEBINFO})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
> +  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
> +endif(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
> +if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
> +  if (CMAKE_BUILD_TYPE MATCHES "Debug")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_DEBUG})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELWITHDEBINFO})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_DARWIN_RELEASE})
> +  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
> +endif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
> +if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
> +  if (CMAKE_BUILD_TYPE MATCHES "Debug")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_DEBUG})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "RelWithDebInfo")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELWITHDEBINFO})
> +  elseif (CMAKE_BUILD_TYPE MATCHES "Release")
> +  set (ENV{LL_BUILD} $ENV{LL_BUILD_LINUX_RELEASE})
> +  endif(CMAKE_BUILD_TYPE MATCHES "Debug")
> +endif(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
>  if ("$ENV{LL_BUILD}" STREQUAL "")
>message(FATAL_ERROR "Environment variable LL_BUILD must be set")
>  endif ()
> -
> +#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
>  # Relative and absolute paths to subtrees.
>
>  if(NOT DEFINED ${CMAKE_CURRENT_LIST_FILE}_INCLUDED)
>
>
>
> On Sat, Jan 7, 2017 at 6:32 PM, Nicky Perian 
> wrote:
>
>> Snip Variables.cmake
>> # Switches set here and in 00-Common.cmake must agree with
>> # https://bitbucket.org/lindenlab/viewer-build-variables/src/
>> tip/variables
>> # Reading $LL_BUILD is an attempt to directly use those switches.
>> #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}'")
>> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
>> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
>> if ("$ENV{LL_BUILD}" STREQUAL "")
>>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
>> endif ()
>>
>> Above allows configure to complete, but I would like a better place or
>> better yet some autobuild involvement to set LL_BUILD based to the chosen
>> Release, RelWithDebugInfo, Debug build.
>>
>> Next,
>> Copyright (C) Microsoft Corporation. All rights reserved.
>>
>> cl : Command line warning D9002: ignoring unknown option '/OP'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/OT'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/O:'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/OR'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/OE'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/OF'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
>> [C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
>> cl : Command line warning D9002: ignoring unknown option
>> '/NODEFAULTLIB:LIBCMT' [C:\Users\Bill\P64\viewer64\bu
>> ild-vc120-64\llcommon\llcommon.vcxproj]
>>
>> No idea where /O* switches are set but appear to be included in every
>> *.vcxproj.
>> 

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Snip Variables.cmake
# Switches set here and in 00-Common.cmake must agree with
# https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables
# Reading $LL_BUILD is an attempt to directly use those switches.
#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}'")
set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
#message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
if ("$ENV{LL_BUILD}" STREQUAL "")
  message(FATAL_ERROR "Environment variable LL_BUILD must be set")
endif ()

Above allows configure to complete, but I would like a better place or
better yet some autobuild involvement to set LL_BUILD based to the chosen
Release, RelWithDebugInfo, Debug build.

Next,
Copyright (C) Microsoft Corporation. All rights reserved.

cl : Command line warning D9002: ignoring unknown option '/OP'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/O:'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OR'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OE'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/OF'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option '/SAFESEH:NO'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]
cl : Command line warning D9002: ignoring unknown option
'/NODEFAULTLIB:LIBCMT'
[C:\Users\Bill\P64\viewer64\build-vc120-64\llcommon\llcommon.vcxproj]

No idea where /O* switches are set but appear to be included in every
*.vcxproj.
'/SAFESEH:NO' and '/NODEFAULTLIB:LIBCMT' or link switches that appear here
LL_BUILD_WINDOWS_BASE_SWITCHES="/Zc:wchar_t- /Zi /GR /DEBUG */SAFESEH:NO
/NODEFAULTLIB:LIBCMT*"

These link switches are set in 00-Common.cmake.

Once removed those warning are no longer listed. This in likely a case of
putting link switches in cl without a pass through. I suspect the '/O*'
switches are link switches also, but grep was of no help finding where they
are set.

Good news is the build completed without the crazy errors encountered
earlier.




On Sat, Jan 7, 2017 at 2:17 PM, Nat Goodspeed  wrote:

> On Fri, Jan 6, 2017 at 9:23 PM, Nicky Perian 
> wrote:
>
> >>/SAFESEH:NO /NODEFAULTLIB:LIBCMT /DLL_RELEASE=1
> /DLL_RLEASE_FOR_DOWNLOAD=1
> >> /DNDEBUG
> >
> > DLL_RLEASE_FOR_DOWNLOAD=1 is the 'E' missing in RELEASE or was the
> variable
> > name changed?
>
> Thank you for pointing that out!
> https://bitbucket.org/lindenlab/viewer-build-variables/commits/
> a9d6c3061349a14289cffb536320f0aa7bdf472f
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Jan 5, 2017 at 8:52 PM, Nicky Perian  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=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=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!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

test script
#!/bin/bash
varsfile="$(mktemp -t vars.)"
autobuild source_environment > "$varsfile"
source "$varsfile"
echo "LL_BUILD = '$LL_BUILD'"

Output
Bill@BILLAW /cygdrive/c/Users/Bill/P64/viewer64
$ bash buildit.sh
LL_BUILD = ''

$varsfile contents

export AUTOBUILD='C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild'
export AUTOBUILD_WIN_VSPLATFORM='Win32'
export AUTOBUILD_CONFIGURE_ARCH='i386'
export AUTOBUILD_VERSION_STRING='1.1.0'
export AUTOBUILD_WIN_CMAKE_GEN='Visual Studio 12'
export AUTOBUILD_PLATFORM='windows'
LL_BUILD_BASE_MACROS='/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_LINUX_RELWITHDEBINFO='-O0 -g -fPIC -DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_BASE='/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32
/D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1
/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_LINUX_RELEASE='-O2 -g -fPIC -DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_DEBUG_SWITCHES='-O0 -g -fPIC'
LL_BUILD_LINUX_RELWITHDEBINFO_MACROS='-DLL_LINUX=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DARWIN_RELEASE_SWITCHES='-O3 -fPIC -gdwarf-2 -stdlib=libc++
-mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_POSIX_BASE_MACROS='-DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_LINUX_BASE='-g -fPIC -DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_RELEASE_MACROS='/DLL_RELEASE=1 /DLL_RLEASE_FOR_DOWNLOAD=1
/DNDEBUG /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO
/NODEFAULTLIB:LIBCMTD /NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG
/SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_DARWIN_BASE_MACROS='-DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DEBUG='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT /D_DEBUG /DLL_DEBUG=1 /D_SCL_SECURE_NO_WARNINGS=1
/D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS
/DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600
/DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB /DLIB_NDOF=1'
LL_BUILD_DARWIN_RELEASE_MACROS='-DLL_RELEASE=1
-DLL_RELEASE_FOR_DOWNLOAD=1 -DNDEBUG -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_LINUX_RELWITHDEBINFO_SWITCHES='-O0 -g -fPIC'
LL_BUILD_RELEASE_SWITCHES='/MD /O2 /Ob2 /INCREMENTAL:NO /OPT:REF
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_RELWITHDEBINFO_SWITCHES='/MD /Od /Ob0 /INCREMENTAL
/Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO /NODEFAULTLIB:LIBCMT'
LL_BUILD_DEBUG_SWITCHES='/MDd /Od /INCREMENTAL:NO /NODEFAULTLIB:LIBCMTD
/NODEFAULTLIB:MSVCRT /Zc:wchar_t- /Zi /GR /DEBUG /SAFESEH:NO
/NODEFAULTLIB:LIBCMT'
LL_BUILD_LINUX_BASE_MACROS='-DLL_LINUX=1 -DLL_OS_DRAGDROP_ENABLED=1
-DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_DARWIN_DEBUG_MACROS='-D_DEBUG -DLL_DEBUG=1 -DPIC -DLL_DARWIN=1
-DLL_OS_DRAGDROP_ENABLED=1 -DCARES_STATICLIB -DLIB_NDOF=1'
LL_BUILD_WINDOWS_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1
/D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 /DCARES_STATICLIB
/DLIB_NDOF=1'
LL_BUILD_DARWIN_RELWITHDEBINFO_SWITCHES='-O0 -fPIC -gdwarf-2
-stdlib=libc++ -mmacosx-version-min=10.9 -iwithsysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/'
LL_BUILD_DEBUG_MACROS='/D_DEBUG /DLL_DEBUG=1
/D_SCL_SECURE_NO_WARNINGS=1 /D_SECURE_STL=0 /D_HAS_ITERATOR_DEBUGGING=0
/DWIN32 /D_WINDOWS /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600
/D_WIN32_WINNT=0x0600 /DLL_OS_DRAGDROP_ENABLED=1 

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>Try creating the env file and reading it. Think about how the UNIX
environment works. >The CMD shell and probably even PowerShell won't see it.

I'm thinking the problem is not being able to execute bash internal
commands such as "eval" and "source" from a windows CMD shell. Programs
such as "tee" work OK but can't reach internals. Next try is to make it
work entirely from cygwin64. Just will be some long commands to reach
autobuild-1.1 which will not be a problem once autobuild-1.1 is standard.

Thanks



On Fri, Jan 6, 2017 at 4:16 AM, Argent  wrote:

> Try creating the env file and reading it. Think about how the UNIX
> environment works. The CMD shell and probably even PowerShell won't see it.
>
> On Jan 5, 2017 19:52, "Nicky Perian"  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.
> Then in the windows command prompt terminal a virtualenv is set to
> autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal
> the virtualenv is lost and cannot be set and autobuild1.0 fails for no
> address-size. From the windows command prompt eval is a cannot find this
> program.
>
> I find it disturbing, to say the least, that the total autobuild cannot be
> completed from the windows command prompt.
>
>
>
>
> On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed  wrote:
>
>> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian 
>> wrote:
>>
>> >>I do not have enough information to know where in your build
>>> environment the disconnect lies.
>>> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
>>> autobuild --address-size=64 configure  -c ReleaseOS --
>>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
>>> -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE  2>&1
>>> |c:\cygwin64\bin\tee -a configRel.log
>>>
>>
>> I could be misinterpreting; you could simply be running the above
>> commands for purposes of creating this mail message. But if this is the
>> command sequence you actually use to configure and build, then autobuild
>> source_environment is not affecting the running environment.
>>
>> autobuild source_environment does not (cannot) directly modify the parent
>> shell's environment variables. It simply writes to its stdout a sequence of
>> variable assignments in bash syntax to be interpreted by the parent shell.
>>
>> You can achieve that either by something like:
>>
>> eval "$(autobuild source_environment)"
>>
>> or something more like:
>>
>> varsfile="$(mktemp -t vars.)"
>> autobuild source_environment > "$varsfile"
>> source "$varsfile"
>>
>> You might consider temporarily adding a command such as:
>>
>> echo "LL_BUILD = '$LL_BUILD'"
>>
>> to ensure that the autobuild source_environment command is in fact having
>> the desired effect.
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

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.
Then in the windows command prompt terminal a virtualenv is set to
autobuild-1.1 and trying to execute autobuild from the Cygwin64 terminal
the virtualenv is lost and cannot be set and autobuild1.0 fails for no
address-size. From the windows command prompt eval is a cannot find this
program.

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




On Thu, Jan 5, 2017 at 4:29 PM, Nat Goodspeed  wrote:

> On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian 
> wrote:
>
> >>I do not have enough information to know where in your build environment
>> the disconnect lies.
>> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
>> autobuild --address-size=64 configure  -c ReleaseOS --
>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
>> -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE  2>&1
>> |c:\cygwin64\bin\tee -a configRel.log
>>
>
> I could be misinterpreting; you could simply be running the above commands
> for purposes of creating this mail message. But if this is the command
> sequence you actually use to configure and build, then autobuild
> source_environment is not affecting the running environment.
>
> autobuild source_environment does not (cannot) directly modify the parent
> shell's environment variables. It simply writes to its stdout a sequence of
> variable assignments in bash syntax to be interpreted by the parent shell.
>
> You can achieve that either by something like:
>
> eval "$(autobuild source_environment)"
>
> or something more like:
>
> varsfile="$(mktemp -t vars.)"
> autobuild source_environment > "$varsfile"
> source "$varsfile"
>
> You might consider temporarily adding a command such as:
>
> echo "LL_BUILD = '$LL_BUILD'"
>
> to ensure that the autobuild source_environment command is in fact having
> the desired effect.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Jan 5, 2017 at 4:41 PM, Nicky Perian  wrote:

>>I do not have enough information to know where in your build environment
> the disconnect lies.
> autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
> autobuild --address-size=64 configure  -c ReleaseOS --
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
> -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE  2>&1
> |c:\cygwin64\bin\tee -a configRel.log
>

I could be misinterpreting; you could simply be running the above commands
for purposes of creating this mail message. But if this is the command
sequence you actually use to configure and build, then autobuild
source_environment is not affecting the running environment.

autobuild source_environment does not (cannot) directly modify the parent
shell's environment variables. It simply writes to its stdout a sequence of
variable assignments in bash syntax to be interpreted by the parent shell.

You can achieve that either by something like:

eval "$(autobuild source_environment)"

or something more like:

varsfile="$(mktemp -t vars.)"
autobuild source_environment > "$varsfile"
source "$varsfile"

You might consider temporarily adding a command such as:

echo "LL_BUILD = '$LL_BUILD'"

to ensure that the autobuild source_environment command is in fact having
the desired effect.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>>I do not have enough information to know where in your build environment
the disconnect lies.
autobuild source_environment 2>&1 |c:\cygwin64\bin\tee configRel.log
autobuild --address-size=64 configure  -c ReleaseOS --
-DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE -DLL_TESTS:BOOL=OFF
-DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=TRUE  2>&1
|c:\cygwin64\bin\tee -a configRel.log
autobuild --verbose  --address-size=64 build  -c ReleaseOS --no-configure
2>&1 |c:\cygwin64\bin\tee BuildRel.log


Environment after running autobuild source_environment
(autobuild-1.1) C:\Users\Bill\P64\viewer64>env
!::=::\
!C:=C:\Users\Bill\P64\viewer64
!ExitCode=
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Bill\AppData\Roaming
asl.log=Destination=file
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
COMMONPROGRAMFILES=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=BILLAW
COMSPEC=C:\WINDOWS\system32\cmd.exe
DXSDK_DIR=C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\
FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
FPS_BROWSER_USER_PROFILE_STRING=Default
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\Bill
KDS_LANGUAGE=13
LOCALAPPDATA=C:\Users\Bill\AppData\Local
LOGONSERVER=\\BILLAW
NUMBER_OF_PROCESSORS=8
OneDrive=C:\Users\Bill\OneDrive
OS=Windows_NT
PATH=/cygdrive/c/Users/Bill/Envs/autobuild-1.1/Scripts:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program
Files (x86)/Intel/iCLS Client:/cygdrive/c/Program Files/Intel/iCLS
Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program
Files (x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine
Components/IPT:/cygdrive/c/Program Files (x86)/Intel/Intel(R) Management
Engine Components/IPT:/cygdrive/c/Program Files (x86)/NVIDIA
Corporation/PhysX/Common:/cygdrive/c/Program
Files/TortoiseHg:/cygdrive/c/Python27:/cygdrive/c/Program Files
(x86)/Windows Kits/8.1/Windows Performance Toolkit:/cygdrive/c/Program
Files/Microsoft SQL Server/110/Tools/Binn:/cygdrive/c/Program Files
(x86)/Microsoft SDKs/TypeScript/1.0:/cygdrive/c/Program Files/Microsoft SQL
Server/120/Tools/Binn:/cygdrive/c/Program Files
(x86)/CMake/bin:/cygdrive/c/Python27/Scripts:/usr/bin:/usr/sbin:/cygdrive/c/Program
Files
(x86)/QuickTime/QTSystem:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/TortoiseGit/bin:/cygdrive/c/Program
Files/doxygen/bin:/cygdrive/c/Program Files (x86)/Midnight
Commander:/cygdrive/c/Users/Bill/AppData/Local/Microsoft/WindowsApps
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 60 Stepping 3, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3c03
ProgramData=C:\ProgramData
PROGRAMFILES=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=(autobuild-1.1) $P$G
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SYSTEMDRIVE=C:
SYSTEMROOT=C:\WINDOWS
TEMP=/cygdrive/c/Users/Bill/AppData/Local/Temp
TMP=/cygdrive/c/Users/Bill/AppData/Local/Temp
USERDOMAIN=BILLAW
USERDOMAIN_ROAMINGPROFILE=BILLAW
USERNAME=Bill
USERPROFILE=C:\Users\Bill
VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\
VENV=autobuild-1.1
VIRTUALENVWRAPPER_PROJECT_FILENAME=.project
VIRTUAL_ENV=C:\Users\Bill\Envs\autobuild-1.1
VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\Tools\
VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\Tools\
WINDIR=C:\WINDOWS
WORKON_HOME=C:\Users\Bill\Envs
_OLD_VIRTUAL_PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS
Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\NVIDIA Corporation\PhysX\Common;C:\Program
Files\TortoiseHg;C:\Python27;C:\Program Files (x86)\Windows
Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL
Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft
SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL
Server\120\Tools\Binn\;C:\Program Files
(x86)\CMake\bin;C:\Python27\Scripts;C:\cygwin64\bin;C:\cygwin64\usr\sbin;C:\Program
Files

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Wed, Jan 4, 2017 at 7:43 PM, Nicky Perian  wrote:

>I'll make the CMake logic die with an error if it doesn't see the
> >LL_BUILD environment variable. That will at least be less obscure than
> >"unexpected type 'S'", and may help identify the problem you're
> >encountering.
>
> I'm back. Still with this hiccup.
>

I assert that when LL_BUILD is set during 'autobuild configure', that is,
at the time CMake is run, and when that LL_BUILD value contains at least
"-DLL_WINDOWS=1" (as in
https://bitbucket.org/lindenlab/viewer-build-variables/src/tip/variables?at=default=file-view-default#variables-26),
the "unexpected type 'S'" problem goes away. We observed that problem
ourselves, and that fixed it for us.

Moreover, when AUTOBUILD_VARIABLES_FILE is set to the pathname of a local
clone of the above-linked file at the time you run 'autobuild
source_environment', the output of 'autobuild source_environment' does
contain a command to set LL_BUILD appropriately.

I do not have enough information to know where in your build environment
the disconnect lies.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Backed out changeset: 54c80e27a54f restore build switches


Building now.


Did notice other avatars are grey. Mine looks fine.


On Wed, Jan 4, 2017 at 6:43 PM, Nicky Perian  wrote:

> >I'll make the CMake logic die with an error if it doesn't see the
> >LL_BUILD environment variable. That will at least be less obscure than
> >"unexpected type 'S'", and may help identify the problem you're
> >encountering.
>
> I'm back. Still with this hiccup.
>
> Nicky
>
> On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed  wrote:
>
>> On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian 
>> wrote:
>>
>> > AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-vari
>> ables\variables
>> > has been set system wide.
>> > Within my configure script (a windows batch file) is autobuild
>> > source_environment and
>> > autobuild configure
>> >
>> > I configure then open vs2013 and the errors continue as before.
>>
>> I'll make the CMake logic die with an error if it doesn't see the
>> LL_BUILD environment variable. That will at least be less obscure than
>> "unexpected type 'S'", and may help identify the problem you're
>> encountering.
>>
>> > Merry Christmas!!
>>
>> You too! And to all a good night!
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>I'll make the CMake logic die with an error if it doesn't see the
>LL_BUILD environment variable. That will at least be less obscure than
>"unexpected type 'S'", and may help identify the problem you're
>encountering.

I'm back. Still with this hiccup.

Nicky

On Thu, Dec 22, 2016 at 2:51 PM, Nat Goodspeed  wrote:

> On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian 
> wrote:
>
> > AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-
> variables\variables
> > has been set system wide.
> > Within my configure script (a windows batch file) is autobuild
> > source_environment and
> > autobuild configure
> >
> > I configure then open vs2013 and the errors continue as before.
>
> I'll make the CMake logic die with an error if it doesn't see the
> LL_BUILD environment variable. That will at least be less obscure than
> "unexpected type 'S'", and may help identify the problem you're
> encountering.
>
> > Merry Christmas!!
>
> You too! And to all a good night!
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Dec 22, 2016 at 2:24 PM, Nicky Perian  wrote:

> AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
> has been set system wide.
> Within my configure script (a windows batch file) is autobuild
> source_environment and
> autobuild configure
>
> I configure then open vs2013 and the errors continue as before.

I'll make the CMake logic die with an error if it doesn't see the
LL_BUILD environment variable. That will at least be less obscure than
"unexpected type 'S'", and may help identify the problem you're
encountering.

> Merry Christmas!!

You too! And to all a good night!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

I have a local repo of
https://bitbucket.org/lindenlab/viewer-build-variables as a sibling of
viewer64.
Just now pulled and updated it.
AUTOBUILD_VARIABLES_FILE=C:\Users\Bill\P64\viewer-build-variables\variables
has been set system wide.
Within my configure script (a windows batch file) is autobuild
source_environment and
​autobuild configure

I configure then open vs2013 and the errors continue as before.

Don't need to pursue til after holidays.

Merry Christmas!!

Nicky
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Dec 22, 2016 at 12:21 PM, Nicky Perian 
wrote:

This is from viewer64 repo w/o changes.
> 0>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
> C2226: syntax error : unexpected type 'S' (C:\Users\Bill\P64\
> viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\
> LLPhysicsExtensionsStubImpl.cpp)
>

Okay. We're trying to unify compile switches across libraries and viewer
builds, so we've introduced
https://bitbucket.org/lindenlab/viewer-build-variables
rather than trying to keep compile switches in sync by hand, which has
historically been troublesome.

The idea is that you clone that repo locally, then set environment variable
AUTOBUILD_VARIABLES_FILE to the 'variables' file within your local
viewer-build-variables clone.

This provides switches and macro definitions that we've previously set in
indra/cmake/00-Common.cmake. In fact I recently pulled the LL_BUILD
environment variable (set by autobuild source_environment when
AUTOBUILD_VARIABLES_FILE is set) into the CMake logic, and eliminated the
switches within 00-Common.cmake now made redundant by the switches in
LL_BUILD.

Among those switches is /DLL_WINDOWS. At this point, if you don't have
AUTOBUILD_VARIABLES_FILE pointing to your local
viewer-build-variables/variables file, you won't have LL_WINDOWS set.

Without LL_WINDOWS, you don't get LL_TYPEOF() defined.

Without LL_TYPEOF(), you get those strange errors.

Naturally we'll be updating all the public documentation to reflect these
things... but we're still evolving all this stuff! Sorry, but by tracking
the bleeding edge of our development, you might occasionally get nicked.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

This is from viewer64 repo w/o changes.
0>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C2226: syntax error : unexpected type 'S'
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>  c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(52)
: see reference to class template instantiation 'LLResultTypeAdd'
being compiled
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C2226: syntax error : unexpected type 'S'
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
10>  c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(52)
: see reference to class template instantiation 'LLResultTypeAdd'
being compiled
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C3646: 'type_t' : unknown override specifier
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C3646: 'type_t' : unknown override specifier
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPhysicsExtensionsStubImpl.cpp)
10>c:\users\bill\p64\viewer64pure\indra\llcommon\llunittype.h(51): error
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
(C:\Users\Bill\P64\viewer64pure\build-vc120-64\packages\llphysicsextensions\stub\LLPathingLibStubImpl.cpp)
1

I suspected that I had stepped on my source so started with a fresh clone.
This kicks off pages of the same error.

On Thu, Dec 22, 2016 at 9:22 AM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

> On 2016-12-22 09:58 , Nat Goodspeed wrote:
>
>
> In general, we have tried to isolate build artifacts under the
> build-whatever directory, in this case build-vc120-32 or build-vc120-64.
> That includes the libraries installed by autobuild: there should be
> separate build-vc120-32/packages and build-vc120-64/packages
> subdirectories. That separation should (!) also include CMake byproducts --
> though if indeed there's some unintentional crossover, I would suspect
> CMake stuff.
>
> Be alert for anything that's starting searches relative to the
> CMAKE_SOURC_DIR/..
>
>
> --
> OZ LINDEN | Engineering Director, Second Life
> email or hangouts: o...@lindenlab.com | Real Life: Scott Lawrence
> LINDEN LAB | Create Virtual Experiences 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Oz Linden (Scott Lawrence)]

On 2016-12-22 09:58 , Nat Goodspeed wrote:


In general, we have tried to isolate build artifacts under the 
build-whatever directory, in this case build-vc120-32 or 
build-vc120-64. That includes the libraries installed by autobuild: 
there should be separate build-vc120-32/packages and 
build-vc120-64/packages subdirectories. That separation should (!) 
also include CMake byproducts -- though if indeed there's some 
unintentional crossover, I would suspect CMake stuff.
Be alert for anything that's starting searches relative to the 
CMAKE_SOURC_DIR/..



--
OZ LINDEN | Engineering Director, Second Life
email or hangouts: o...@lindenlab.com  | Real 
Life: Scott Lawrence

LINDEN LAB | Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Dec 22, 2016 at 8:29 AM, Nicky Perian  wrote:

I haven't confirmed, but there may be an issue with having build-vc120-32
> and build-vc120-64 side by side and pickup of library dependencies when
> switching from one build to the other.
>

Please let us know what you find out.

In general, we have tried to isolate build artifacts under the
build-whatever directory, in this case build-vc120-32 or build-vc120-64.
That includes the libraries installed by autobuild: there should be
separate build-vc120-32/packages and build-vc120-64/packages
subdirectories. That separation should (!) also include CMake byproducts --
though if indeed there's some unintentional crossover, I would suspect
CMake stuff.

Don't be dismayed if, when you post your findings, we don't respond right
away: today is the last day before Linden's holiday break. We'll be back
online, much refreshed, on Tuesday, January 3rd.

Merry Christmas!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

I haven't confirmed, but there may be an issue with having build-vc120-32
and build-vc120-64 side by side and pickup of library dependencies when
switching from one build to the other.




On Wed, Dec 14, 2016 at 7:56 PM, Nat Goodspeed  wrote:

> On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian 
> wrote:
>
> While building my own 64 bit fmodex archive I had an issue with "autobuild
>> --address-size=64 build".
>> autobuild would not build a 64 bit variant. Once I added "export
>> AUTOBUILD_PLATFORM_OVERRIDE='darwin64'" I was able to produce the 64 bit
>> archive.
>>
>> I have not repro'ed because once I had the archive I didn't care to go
>> back through it.
>>
>
> Two comments...
>
> First, it appears that autobuild's argument parsing is sensitive to
> options before vs. after the subcommand. I always use "autobuild build -A
> 64", which works. I don't know why it doesn't work equally well the other
> way, but yours is not the first time I've seen a similar complaint.
>
> Second, I'm glad that the fmodex build responded well to the override.
> Just last week I had to tweak the build-cmd.sh scripts for both jsoncpp and
> breakpad because their build systems were not forwarding the architecture
> or address size properly, and the "darwin64" build was still producing
> 32-bit libraries. I'm not yet convinced that we've seen the last of that
> issue; just be aware that that might be the cause of observed problems.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Wed, Dec 14, 2016 at 7:13 PM, Nicky Perian  wrote:

While building my own 64 bit fmodex archive I had an issue with "autobuild
> --address-size=64 build".
> autobuild would not build a 64 bit variant. Once I added "export
> AUTOBUILD_PLATFORM_OVERRIDE='darwin64'" I was able to produce the 64 bit
> archive.
>
> I have not repro'ed because once I had the archive I didn't care to go
> back through it.
>

Two comments...

First, it appears that autobuild's argument parsing is sensitive to options
before vs. after the subcommand. I always use "autobuild build -A 64",
which works. I don't know why it doesn't work equally well the other way,
but yours is not the first time I've seen a similar complaint.

Second, I'm glad that the fmodex build responded well to the override. Just
last week I had to tweak the build-cmd.sh scripts for both jsoncpp and
breakpad because their build systems were not forwarding the architecture
or address size properly, and the "darwin64" build was still producing
32-bit libraries. I'm not yet convinced that we've seen the last of that
issue; just be aware that that might be the cause of observed problems.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

macOS with autobuild-1.1

While building my own 64 bit fmodex archive I had an issue with "autobuild
--address-size=64 build".
autobuild would not build a 64 bit variant. Once I added "export
AUTOBUILD_PLATFORM_OVERRIDE='darwin64'" I was able to produce the 64 bit
archive.

I have not repro'ed because once I had the archive I didn't care to go back
through it.

Just an fyi.

Nicky







On Fri, Dec 9, 2016 at 4:11 AM, Henri Beauchamp  wrote:

> On Thu, 8 Dec 2016 18:07:42 -0600, Nicky Perian wrote:
>
> > Possible Correction, Parts of this were in declined Pull Request #4
> > This is windows only Darwin and Linux will need a similar code.
>
> Not needed for Darwin (the FMOD Ex Darwin library is a fat binary with
> both 32 and 64 bits code in it).
>
> For Linux, just add:
>   elseif (LINUX)
> if (ADDRESS_SIZE EQUAL 64)
>   set(FMODEX_LIBRARY
>   debug fmodexL64
>   optimized fmodex64)
> else (ADDRESS_SIZE EQUAL 64)
>   set(FMODEX_LIBRARY
>   debug fmodexL
>   optimized fmodex)
> endif (ADDRESS_SIZE EQUAL 64)
>
>
> Henri.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Henri Beauchamp]

On Thu, 8 Dec 2016 18:07:42 -0600, Nicky Perian wrote:

> Possible Correction, Parts of this were in declined Pull Request #4
> This is windows only Darwin and Linux will need a similar code.

Not needed for Darwin (the FMOD Ex Darwin library is a fat binary with
both 32 and 64 bits code in it).

For Linux, just add:
  elseif (LINUX)
if (ADDRESS_SIZE EQUAL 64)
  set(FMODEX_LIBRARY 
  debug fmodexL64
  optimized fmodex64)
else (ADDRESS_SIZE EQUAL 64)
  set(FMODEX_LIBRARY 
  debug fmodexL
  optimized fmodex)
endif (ADDRESS_SIZE EQUAL 64)


Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Fault:
LINK : fatal error LNK1181: cannot open input file 'fmodex_vc.lib'
[C:\Users\Bill\P64\viewer64\build-vc120-64\newview\secondlife-bin.vcxproj]

Possible Correction, Parts of this were in declined Pull Request #4
This is windows only Darwin and Linux will need a similar code.
# HG changeset patch
# User Nicky Perian 
# Date 1480710394 21600
#  Fri Dec 02 14:26:34 2016 -0600
# Node ID f70e1917b449af35d719e3a572694c6768d87254
# Parent  290ae1d71523ee22a079421d4fdeee4225a9f7cc
Provide for x64 FMOD ex libraries

diff -r 290ae1d71523 -r f70e1917b449 indra/cmake/Copy3rdPartyLibs.cmake
--- a/indra/cmake/Copy3rdPartyLibs.cmake Wed Dec 07 22:50:25 2016 -0500
+++ b/indra/cmake/Copy3rdPartyLibs.cmake Fri Dec 02 14:26:34 2016 -0600
@@ -43,12 +43,12 @@
 )

 if (FMODEX)
-
-if(ADDRESS_SIZE EQUAL 32)
+if (ADDRESS_SIZE EQUAL 32)
 set(release_files ${release_files} fmodex.dll)
-else(ADDRESS_SIZE EQUAL 32)
+elseif (ADDRESS_SIZE EQUAL 64)
 set(release_files ${release_files} fmodex64.dll)
-endif(ADDRESS_SIZE EQUAL 32)
+endif (ADDRESS_SIZE EQUAL 32)
+#  set(debug_files ${debug_files} fmodexL.dll)
 endif (FMODEX)

 #***
diff -r 290ae1d71523 -r f70e1917b449 indra/cmake/FMODEX.cmake
--- a/indra/cmake/FMODEX.cmake Wed Dec 07 22:50:25 2016 -0500
+++ b/indra/cmake/FMODEX.cmake Fri Dec 02 14:26:34 2016 -0600
@@ -26,10 +26,16 @@
   include(Prebuilt)
   use_prebuilt_binary(fmodex)
   if (WINDOWS)
-set(FMODEX_LIBRARY
-debug fmodexL_vc
-optimized fmodex_vc)
-  elseif (DARWIN)
+if (ADDRESS_SIZE EQUAL 32)
+set(FMODEX_LIBRARY
+debug fmodexL_vc
+optimized fmodex_vc)
+elseif (ADDRESS_SIZE EQUAL 64)
+set(FMODEX_LIBRARY
+debug fmodexL64_vc
+optimized fmodex64_vc)
+endif (ADDRESS_SIZE EQUAL 32)
+elseif (DARWIN)
 set(FMODEX_LIBRARY
 debug fmodexL
 optimized fmodex)


On Sat, Dec 3, 2016 at 7:32 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> woohoo - thanks nicky.
>
> On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian 
> wrote:
>
>> *only issue is that some script is trying to copy fmodex.dll to the right
>> place and not (the correct) fmodex64.dll (I fixed the third party package).*
>>
>> It's fixed at:
>> https://bitbucket.org/kokua/viewer64/commits/ca4ffedff48cf4a
>> e29622434567a59f6b010708b
>>
>> On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <
>> cal...@lindenlab.com> wrote:
>>
>>> Yep - we;re all following along similar tracks by the sound of it Nicky
>>>  :)
>>>
>>> With my latest changes, if I unload the VLC plugin (as you say, that
>>> needs a little work) the build completes - only issue is that some script
>>> is trying to copy fmodex.dll to the right place and not (the correct)
>>> fmodex64.dll (I fixed the third party package).
>>>
>>> If I move that DLL manually, the viewer starts and seems to run, as
>>> first glance anyway, pretty normally.
>>>
>>> I'll attack the fmodex and vlc issues on Monday.
>>>
>>>
>>>
>>> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed  wrote:
>>>
 On Dec 3, 2016 7:18 PM, "Nicky Perian"  wrote:

 With:
 (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
 configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
 -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
 -DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log

 I get many:

 No windows64 configuration found; inheriting windows

 But, build-vc120-64/packages has 64 bit libraries and the viewer builds
 64 bit and it runs.


 Yes: we've been discussing those messages internally. The viewer's
 CMake logic runs autobuild install for each applicable package, and I think
 the messages you're seeing are simply from autobuild waking up each time
 and reading autobuild.xml. In other words, I believe the message is about
 the package_description rather than any of the installables.

 We really want to avoid duplicating all of the windows section of
 autobuild.xml for windows64, which is why we added $parameter support in
 autobuild 1.1. So we don't plan to add a windows64 section to
 package_description.

 vlc plugin had may unresolved externals so, commented it out in
 media-plugins CMakeLists.txt in order to complete the build.

 This was with viewer64-callum changes merged in.


 I'm pretty sure Callum disabled VLC too, though perhaps that's only
 local so far.

 We're really at about the same point! Please bear with us. :-)

 ___
 Policies and (un)subscribe information available here:

Re: [opensource-dev] 64 bit viewers build instructions

[Henri Beauchamp]

On Sat, 3 Dec 2016 19:12:31 -0600, Nicky Perian wrote:

> *only issue is that some script is trying to copy fmodex.dll

Speaking of FMOD Ex, you might want to update it. The current version
is v4.44.64 and got crash fixes over the one you are using...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Callum Prentice (Callum)]

woohoo - thanks nicky.

On Sat, Dec 3, 2016 at 5:12 PM, Nicky Perian  wrote:

> *only issue is that some script is trying to copy fmodex.dll to the right
> place and not (the correct) fmodex64.dll (I fixed the third party package).*
>
> It's fixed at:
> https://bitbucket.org/kokua/viewer64/commits/
> ca4ffedff48cf4ae29622434567a59f6b010708b
>
> On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
>> Yep - we;re all following along similar tracks by the sound of it Nicky
>>  :)
>>
>> With my latest changes, if I unload the VLC plugin (as you say, that
>> needs a little work) the build completes - only issue is that some script
>> is trying to copy fmodex.dll to the right place and not (the correct)
>> fmodex64.dll (I fixed the third party package).
>>
>> If I move that DLL manually, the viewer starts and seems to run, as first
>> glance anyway, pretty normally.
>>
>> I'll attack the fmodex and vlc issues on Monday.
>>
>>
>>
>> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed  wrote:
>>
>>> On Dec 3, 2016 7:18 PM, "Nicky Perian"  wrote:
>>>
>>> With:
>>> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
>>> configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
>>> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
>>> -DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log
>>>
>>> I get many:
>>>
>>> No windows64 configuration found; inheriting windows
>>>
>>> But, build-vc120-64/packages has 64 bit libraries and the viewer builds
>>> 64 bit and it runs.
>>>
>>>
>>> Yes: we've been discussing those messages internally. The viewer's CMake
>>> logic runs autobuild install for each applicable package, and I think the
>>> messages you're seeing are simply from autobuild waking up each time and
>>> reading autobuild.xml. In other words, I believe the message is about the
>>> package_description rather than any of the installables.
>>>
>>> We really want to avoid duplicating all of the windows section of
>>> autobuild.xml for windows64, which is why we added $parameter support in
>>> autobuild 1.1. So we don't plan to add a windows64 section to
>>> package_description.
>>>
>>> vlc plugin had may unresolved externals so, commented it out in
>>> media-plugins CMakeLists.txt in order to complete the build.
>>>
>>> This was with viewer64-callum changes merged in.
>>>
>>>
>>> I'm pretty sure Callum disabled VLC too, though perhaps that's only
>>> local so far.
>>>
>>> We're really at about the same point! Please bear with us. :-)
>>>
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>>
>> --
>>
>> CALLUM PRENTICE | Software Engineer
>>
>> LINDEN LAB | Create Virtual Experiences 
>>
>
>


-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

*only issue is that some script is trying to copy fmodex.dll to the right
place and not (the correct) fmodex64.dll (I fixed the third party package).*

It's fixed at:
https://bitbucket.org/kokua/viewer64/commits/ca4ffedff48cf4ae29622434567a59f6b010708b

On Sat, Dec 3, 2016 at 7:07 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> Yep - we;re all following along similar tracks by the sound of it Nicky  :)
>
> With my latest changes, if I unload the VLC plugin (as you say, that needs
> a little work) the build completes - only issue is that some script is
> trying to copy fmodex.dll to the right place and not (the correct)
> fmodex64.dll (I fixed the third party package).
>
> If I move that DLL manually, the viewer starts and seems to run, as first
> glance anyway, pretty normally.
>
> I'll attack the fmodex and vlc issues on Monday.
>
>
>
> On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed  wrote:
>
>> On Dec 3, 2016 7:18 PM, "Nicky Perian"  wrote:
>>
>> With:
>> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
>> configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
>> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
>> -DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log
>>
>> I get many:
>>
>> No windows64 configuration found; inheriting windows
>>
>> But, build-vc120-64/packages has 64 bit libraries and the viewer builds
>> 64 bit and it runs.
>>
>>
>> Yes: we've been discussing those messages internally. The viewer's CMake
>> logic runs autobuild install for each applicable package, and I think the
>> messages you're seeing are simply from autobuild waking up each time and
>> reading autobuild.xml. In other words, I believe the message is about the
>> package_description rather than any of the installables.
>>
>> We really want to avoid duplicating all of the windows section of
>> autobuild.xml for windows64, which is why we added $parameter support in
>> autobuild 1.1. So we don't plan to add a windows64 section to
>> package_description.
>>
>> vlc plugin had may unresolved externals so, commented it out in
>> media-plugins CMakeLists.txt in order to complete the build.
>>
>> This was with viewer64-callum changes merged in.
>>
>>
>> I'm pretty sure Callum disabled VLC too, though perhaps that's only local
>> so far.
>>
>> We're really at about the same point! Please bear with us. :-)
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Callum Prentice (Callum)]

Yep - we;re all following along similar tracks by the sound of it Nicky  :)

With my latest changes, if I unload the VLC plugin (as you say, that needs
a little work) the build completes - only issue is that some script is
trying to copy fmodex.dll to the right place and not (the correct)
fmodex64.dll (I fixed the third party package).

If I move that DLL manually, the viewer starts and seems to run, as first
glance anyway, pretty normally.

I'll attack the fmodex and vlc issues on Monday.



On Sat, Dec 3, 2016 at 4:35 PM, Nat Goodspeed  wrote:

> On Dec 3, 2016 7:18 PM, "Nicky Perian"  wrote:
>
> With:
> (autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
> configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
> -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
> -DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log
>
> I get many:
>
> No windows64 configuration found; inheriting windows
>
> But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
> bit and it runs.
>
>
> Yes: we've been discussing those messages internally. The viewer's CMake
> logic runs autobuild install for each applicable package, and I think the
> messages you're seeing are simply from autobuild waking up each time and
> reading autobuild.xml. In other words, I believe the message is about the
> package_description rather than any of the installables.
>
> We really want to avoid duplicating all of the windows section of
> autobuild.xml for windows64, which is why we added $parameter support in
> autobuild 1.1. So we don't plan to add a windows64 section to
> package_description.
>
> vlc plugin had may unresolved externals so, commented it out in
> media-plugins CMakeLists.txt in order to complete the build.
>
> This was with viewer64-callum changes merged in.
>
>
> I'm pretty sure Callum disabled VLC too, though perhaps that's only local
> so far.
>
> We're really at about the same point! Please bear with us. :-)
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Dec 3, 2016 7:18 PM, "Nicky Perian"  wrote:

With:
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log

I get many:

No windows64 configuration found; inheriting windows

But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
bit and it runs.


Yes: we've been discussing those messages internally. The viewer's CMake
logic runs autobuild install for each applicable package, and I think the
messages you're seeing are simply from autobuild waking up each time and
reading autobuild.xml. In other words, I believe the message is about the
package_description rather than any of the installables.

We really want to avoid duplicating all of the windows section of
autobuild.xml for windows64, which is why we added $parameter support in
autobuild 1.1. So we don't plan to add a windows64 section to
package_description.

vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.

This was with viewer64-callum changes merged in.


I'm pretty sure Callum disabled VLC too, though perhaps that's only local
so far.

We're really at about the same point! Please bear with us. :-)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

With:
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64
configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE
-DFMODEX:BOOL=ON2>&1  | c:\cygwin64\bin\tee configRel.log

I get many:

No windows64 configuration found; inheriting windows

But, build-vc120-64/packages has 64 bit libraries and the viewer builds 64
bit and it runs.

vlc plugin had may unresolved externals so, commented it out in
media-plugins CMakeLists.txt in order to complete the build.

This was with viewer64-callum changes merged in.

Attached is the configure log.






On Fri, Dec 2, 2016 at 9:25 AM, Nicky Perian  wrote:

> RE: Windows 64 bit cmake identifier.
> What cmake variable is going to be used within cmake for branching 32 vs
> 64 bit builds?
>
> Example FMODEX.cmake.
>
> Friestorm uses  if( NOT ND_BUILD64BIT_ARCH ) which is very specific to
> their build system.
>
> So, will it be ARCH or ADDRESS_SIZE or a new variable combining these?
>
>
>
>
> On Wed, Nov 30, 2016 at 5:12 PM, Monty Brandenberg 
> wrote:
>
>> On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
>> >
>> > I think we decided back when switching to VS 2013 that /GL and /LTCG
>> > didn't add enough value for us to bother with them. I think the
>> > expedient fix would be to remove /GL from jpeglib.
>>
>> I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
>> in the cmake directory get updated with current options and the
>> thinking that led to them...
>>
>> m
>>
>> --
>> Monty Brandenberg | Unit of Production
>> Skype monty.linden | Second Life Monty Linden
>>
>> Linden Lab | Makers of Shared Creative Spaces
>> Check out what we're working on!
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
(autobuild-1.1) C:\Users\Bill\P64\viewer64>autobuild --address-size=64 
configure  -c ReleaseOS -- -DCMAKE_VERBOSE_MAKEFILE:BOOL=FALSE 
-DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=FALSE  -DOPENAL:BOOL=FALSE -DFMODEX:BOOL=ON  
  2>&1  | c:\cygwin64\bin\tee configRel.log
Warning: no --id argument or AUTOBUILD_BUILD_ID environment variable specified;
using the date and time (201612030806), which may not be unique
No windows64 configuration found; inheriting windows
-- Revision (from hg) 36447
-- Building 'Second Life Test' Version 4.1.3.36447
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
-- Copying redist libs for VC 12.0
-- Copying redist libs for VC 10.0
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
No windows64 configuration found; inheriting windows
Copying icons for test
-- Configuring done
CMake Warning (dev) at media_plugins/libvlc/CMakeLists.txt:61 
(add_dependencies):
  Policy CMP0046 is not set: Error on non-existent dependency in
  add_dependencies.  Run "cmake --help-policy CMP0046" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  The dependency target "debug" of target "media_plugin_libvlc" does not
  exist.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at media_plugins/libvlc/CMakeLists.txt:61 
(add_dependencies):
  Policy CMP0046 is not set: Error on non-existent dependency in
  add_dependencies.  Run "cmake 

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

RE: Windows 64 bit cmake identifier.
What cmake variable is going to be used within cmake for branching 32 vs 64
bit builds?

Example FMODEX.cmake.

Friestorm uses  if( NOT ND_BUILD64BIT_ARCH ) which is very specific to
their build system.

So, will it be ARCH or ADDRESS_SIZE or a new variable combining these?




On Wed, Nov 30, 2016 at 5:12 PM, Monty Brandenberg 
wrote:

> On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
> >
> > I think we decided back when switching to VS 2013 that /GL and /LTCG
> > didn't add enough value for us to bother with them. I think the
> > expedient fix would be to remove /GL from jpeglib.
>
> I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
> in the cmake directory get updated with current options and the
> thinking that led to them...
>
> m
>
> --
> Monty Brandenberg | Unit of Production
> Skype monty.linden | Second Life Monty Linden
>
> Linden Lab | Makers of Shared Creative Spaces
> Check out what we're working on!
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Monty Brandenberg]

On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
>
> I think we decided back when switching to VS 2013 that /GL and /LTCG
> didn't add enough value for us to bother with them. I think the
> expedient fix would be to remove /GL from jpeglib.

I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt
in the cmake directory get updated with current options and the
thinking that led to them...

m

-- 
Monty Brandenberg | Unit of Production
Skype monty.linden | Second Life Monty Linden

Linden Lab | Makers of Shared Creative Spaces
Check out what we're working on!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Disregard, It was a viewer cmake for llimagej2coj
that did not work.

${OPENJPEG_LIBRARIES}
 )
+if (WINDOWS)
+  set_target_properties(
+llimagej2coj
+PROPERTIES
+LINK_FLAGS "/MANIFEST:NO /SAFESEH:NO /LTCG /NODEFAULTLIB:LIBCMT"
+LINK_FLAGS_DEBUG "/MANIFEST:NO /SAFESEH:NO /NODEFAULTLIB:LIBCMTD"
+)
+endif (WINDOWS)
\ No newline at end of file



On Wed, Nov 30, 2016 at 3:48 PM, Nicky Perian  wrote:

> >> Is it just a question of add /LTCG to the jpeglib link command?
>
> I tired that and it didn't change anything.
>
>
> On Wed, Nov 30, 2016 at 3:04 PM, Callum Prentice (Callum) <
> cal...@lindenlab.com> wrote:
>
>> I'd like to fix that too.
>>
>> Is it just a question of add /LTCG to the jpeglib link command?  I see
>> that's done via an nmake makefile and then build via a .sln but I think I
>> see where to add that command.
>>
>> On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian 
>> wrote:
>>
>>> Would this be a good time to fix this warning?
>>>
>>>   jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
>>> found; restarting link with /LTCG; add /LTCG to the link command line to
>>> improve linker performance
>>>
>>> Thanks
>>>
>>> On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed 
>>> wrote:
>>>
 On Nov 29, 2016 11:11 PM, "Nicky Perian"  wrote:

 > I am unable to get a windows 64 bit build environment. A learning
 issue for me.
 > What commands do you use to switch to 64 bit?

 I use:

 autobuild build --address-size=64

 :-)

 But I don't yet have a clean 64-bit build on any platform.

>>>
>>>
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>>
>> --
>>
>> CALLUM PRENTICE | Software Engineer
>>
>> LINDEN LAB | Create Virtual Experiences 
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>> Is it just a question of add /LTCG to the jpeglib link command?

I tired that and it didn't change anything.


On Wed, Nov 30, 2016 at 3:04 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

> I'd like to fix that too.
>
> Is it just a question of add /LTCG to the jpeglib link command?  I see
> that's done via an nmake makefile and then build via a .sln but I think I
> see where to add that command.
>
> On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian 
> wrote:
>
>> Would this be a good time to fix this warning?
>>
>>   jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
>> found; restarting link with /LTCG; add /LTCG to the link command line to
>> improve linker performance
>>
>> Thanks
>>
>> On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed 
>> wrote:
>>
>>> On Nov 29, 2016 11:11 PM, "Nicky Perian"  wrote:
>>>
>>> > I am unable to get a windows 64 bit build environment. A learning
>>> issue for me.
>>> > What commands do you use to switch to 64 bit?
>>>
>>> I use:
>>>
>>> autobuild build --address-size=64
>>>
>>> :-)
>>>
>>> But I don't yet have a clean 64-bit build on any platform.
>>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
>
> CALLUM PRENTICE | Software Engineer
>
> LINDEN LAB | Create Virtual Experiences 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Wed, Nov 30, 2016 at 4:04 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:

Is it just a question of add /LTCG to the jpeglib link command?  I see
> that's done via an nmake makefile and then build via a .sln but I think I
> see where to add that command.
>

I think we decided back when switching to VS 2013 that /GL and /LTCG didn't
add enough value for us to bother with them. I think the expedient fix
would be to remove /GL from jpeglib.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Callum Prentice (Callum)]

I'd like to fix that too.

Is it just a question of add /LTCG to the jpeglib link command?  I see
that's done via an nmake makefile and then build via a .sln but I think I
see where to add that command.

On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian  wrote:

> Would this be a good time to fix this warning?
>
>   jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
> found; restarting link with /LTCG; add /LTCG to the link command line to
> improve linker performance
>
> Thanks
>
> On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed  wrote:
>
>> On Nov 29, 2016 11:11 PM, "Nicky Perian"  wrote:
>>
>> > I am unable to get a windows 64 bit build environment. A learning issue
>> for me.
>> > What commands do you use to switch to 64 bit?
>>
>> I use:
>>
>> autobuild build --address-size=64
>>
>> :-)
>>
>> But I don't yet have a clean 64-bit build on any platform.
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 

CALLUM PRENTICE | Software Engineer

LINDEN LAB | Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Would this be a good time to fix this warning?

  jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
found; restarting link with /LTCG; add /LTCG to the link command line to
improve linker performance

Thanks

On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed  wrote:

> On Nov 29, 2016 11:11 PM, "Nicky Perian"  wrote:
>
> > I am unable to get a windows 64 bit build environment. A learning issue
> for me.
> > What commands do you use to switch to 64 bit?
>
> I use:
>
> autobuild build --address-size=64
>
> :-)
>
> But I don't yet have a clean 64-bit build on any platform.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Nov 29, 2016 11:11 PM, "Nicky Perian"  wrote:

> I am unable to get a windows 64 bit build environment. A learning issue
for me.
> What commands do you use to switch to 64 bit?

I use:

autobuild build --address-size=64

:-)

But I don't yet have a clean 64-bit build on any platform.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Thanks, I'll return to poking at it.

I am unable to get a windows 64 bit build environment. A learning issue for
me.
What commands do you use to switch to 64 bit?



On Tue, Nov 29, 2016 at 8:37 PM, Nat Goodspeed  wrote:

> On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian 
> wrote:
>
> Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64
>> openjpeg needs work, The lib names in openjpeg.cmake don't match the new
>> lib names and there is an archive include file issue. Once the include
>> files are provided then that just opens the box for un-defines at link.
>>
>
> Okay, I've rebuilt p64 openjpeg at 1.5.1. The current tip of
> lindenlab/viewer64 pulls in that package, and with those changes I get a
> clean local windows 32-bit build. (Other platforms still very much up in
> the air.)
>
>
>> cef flip issues have returned.
>>
>
> My p64 llceflib wasn't actively tracking the production llceflib repo,
> sorry. Callum is currently working up a new package for viewer64.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Sat, Nov 26, 2016 at 11:37 PM, Nicky Perian 
wrote:

Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64
> openjpeg needs work, The lib names in openjpeg.cmake don't match the new
> lib names and there is an archive include file issue. Once the include
> files are provided then that just opens the box for un-defines at link.
>

Okay, I've rebuilt p64 openjpeg at 1.5.1. The current tip of
lindenlab/viewer64 pulls in that package, and with those changes I get a
clean local windows 32-bit build. (Other platforms still very much up in
the air.)


> cef flip issues have returned.
>

My p64 llceflib wasn't actively tracking the production llceflib repo,
sorry. Callum is currently working up a new package for viewer64.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Was able to complete a win32 build, but had to revert to openjpeg 1.4. P64
openjpeg needs work, The lib names in openjpeg.cmake don't match the new
lib names and there is an archive include file issue. Once the include
files are provided then that just opens the box for un-defines at link.

cef flip issues have returned.





On Thu, Nov 24, 2016 at 5:49 PM, Nicky Perian  wrote:

> Happy Thanksgiving. @Nat, I really didn't expect an answer until next
> week, hoping it was minimal interruption to your Thanksgiving .
>
> My family just finished a wonderful traditional meal, that is, if you can
> call possum pie traditional.
>
>
>
> On Thu, Nov 24, 2016 at 4:51 PM, Nat Goodspeed  wrote:
>
>> On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian 
>> wrote:
>>
>> Which windows command prompt should be used? I have used Developer
>>> Command Prompt for VS2013
>>> which defaults to 32 bit tool set via %comspec% /k ""C:\Program Files
>>> (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
>>> The C:\Users\Bill\P64\viewer-build-variables\convenience script, at
>>> default, also sets a 32 bit tool set.
>>>
>>> So, what terminal should be used for 64 bit? VS2013 x64 Native Tools
>>> Command Prompt sets 64 bit tool sets via
>>> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
>>> 12.0\VC\vcvarsall.bat"" amd64? Or, will the convenience script set the
>>> system build variables and pick the proper tool set regardless of which
>>> terminal is used?
>>>
>>
>> Please update your autobuild-1.1 from https://bitbucket.org/lindenla
>> b/autobuild-1.1 . In the last couple days I pushed a change that makes
>> autobuild build use its --address-size switch, along with the
>> AUTOBUILD_VSVER environment variable, to set the environment (notably the
>> PATH) to run the command specified in autobuild.xml.
>>
>> (It actually looks up the VSnnnCOMNTOOLS environment variable selected by
>> AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
>> those variables.)
>>
>> On a plain prompt on my system, with no vcvarsall.bat active, that
>> permits me to run either 32-bit or 64-bit builds depending on the
>> --address-size (-A) switch.
>>
>>
>>> Next question, what distro and gcc version is being used for linux
>>> builds?
>>>
>>
>> The near-term answer is that we need to be able to build on Debian wheezy
>> with gcc 4.7.
>>
>> Our ops team is busily working up Debian jessie images, but that's not
>> yet available. I don't know off the top of my head what gcc version is the
>> default on jessie, but for now it's moot.
>>
>> P.S. I will have a better fix for the llceflib problem, along with a fix
>> for the openjpeg issues, next week. Happy Thanksgiving!
>>
>>
>> --
>> NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN
>> LAB | Create Virtual Experiences 
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Happy Thanksgiving. @Nat, I really didn't expect an answer until next week,
hoping it was minimal interruption to your Thanksgiving .

My family just finished a wonderful traditional meal, that is, if you can
call possum pie traditional.



On Thu, Nov 24, 2016 at 4:51 PM, Nat Goodspeed  wrote:

> On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian 
> wrote:
>
> Which windows command prompt should be used? I have used Developer Command
>> Prompt for VS2013
>> which defaults to 32 bit tool set via %comspec% /k ""C:\Program Files
>> (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
>> The C:\Users\Bill\P64\viewer-build-variables\convenience script, at
>> default, also sets a 32 bit tool set.
>>
>> So, what terminal should be used for 64 bit? VS2013 x64 Native Tools
>> Command Prompt sets 64 bit tool sets via
>> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
>> 12.0\VC\vcvarsall.bat"" amd64? Or, will the convenience script set the
>> system build variables and pick the proper tool set regardless of which
>> terminal is used?
>>
>
> Please update your autobuild-1.1 from https://bitbucket.org/
> lindenlab/autobuild-1.1 . In the last couple days I pushed a change that
> makes autobuild build use its --address-size switch, along with the
> AUTOBUILD_VSVER environment variable, to set the environment (notably the
> PATH) to run the command specified in autobuild.xml.
>
> (It actually looks up the VSnnnCOMNTOOLS environment variable selected by
> AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
> those variables.)
>
> On a plain prompt on my system, with no vcvarsall.bat active, that permits
> me to run either 32-bit or 64-bit builds depending on the --address-size
> (-A) switch.
>
>
>> Next question, what distro and gcc version is being used for linux
>> builds?
>>
>
> The near-term answer is that we need to be able to build on Debian wheezy
> with gcc 4.7.
>
> Our ops team is busily working up Debian jessie images, but that's not yet
> available. I don't know off the top of my head what gcc version is the
> default on jessie, but for now it's moot.
>
> P.S. I will have a better fix for the llceflib problem, along with a fix
> for the openjpeg issues, next week. Happy Thanksgiving!
>
>
> --
> NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN
> LAB | Create Virtual Experiences 
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Thu, Nov 24, 2016 at 2:19 PM, Nicky Perian  wrote:

Which windows command prompt should be used? I have used Developer Command
> Prompt for VS2013
> which defaults to 32 bit tool set via %comspec% /k ""C:\Program Files
> (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
> The C:\Users\Bill\P64\viewer-build-variables\convenience script, at
> default, also sets a 32 bit tool set.
>
> So, what terminal should be used for 64 bit? VS2013 x64 Native Tools
> Command Prompt sets 64 bit tool sets via
> %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
> 12.0\VC\vcvarsall.bat"" amd64? Or, will the convenience script set the
> system build variables and pick the proper tool set regardless of which
> terminal is used?
>

Please update your autobuild-1.1 from
https://bitbucket.org/lindenlab/autobuild-1.1 . In the last couple days I
pushed a change that makes autobuild build use its --address-size switch,
along with the AUTOBUILD_VSVER environment variable, to set the environment
(notably the PATH) to run the command specified in autobuild.xml.

(It actually looks up the VSnnnCOMNTOOLS environment variable selected by
AUTOBUILD_VSVER=nnn and internally runs the relevant .bat files to set
those variables.)

On a plain prompt on my system, with no vcvarsall.bat active, that permits
me to run either 32-bit or 64-bit builds depending on the --address-size
(-A) switch.


> Next question, what distro and gcc version is being used for linux builds?
>

The near-term answer is that we need to be able to build on Debian wheezy
with gcc 4.7.

Our ops team is busily working up Debian jessie images, but that's not yet
available. I don't know off the top of my head what gcc version is the
default on jessie, but for now it's moot.

P.S. I will have a better fix for the llceflib problem, along with a fix
for the openjpeg issues, next week. Happy Thanksgiving!


-- 
NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN LAB
| Create Virtual Experiences 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

Which windows command prompt should be used? I have used Developer Command
Prompt for VS2013
which defaults to 32 bit tool set via %comspec% /k ""C:\Program Files
(x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""
The C:\Users\Bill\P64\viewer-build-variables\convenience script, at
default, also sets a 32 bit tool set.

So, what terminal should be used for 64 bit? VS2013 x64 Native Tools
Command Prompt sets 64 bit tool sets via
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat"" amd64? Or, will the convenience script set the
system build variables and pick the proper tool set regardless of which
terminal is used?

Next question, what distro and gcc version is being used for linux builds?

On Wed, Nov 23, 2016 at 12:11 PM, Nat Goodspeed  wrote:

> On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian 
> wrote:
>
> This is on a Release. The solution defaulted to Debug and I failed to
>> notice.
>> So, that raises the question; Why when autobuild source_environment is
>> set to Release did it not follow through to the soultion?
>>
>
> There is a program called VSTool in indra/tools/vstool that has been used
> to postprocess the .sln file generated by autobuild configure (running
> CMake). We recently stopped running that implicitly, for a couple reasons:
>
>
>1. VSTool began failing intermittently on our build machines,
>impacting the reliability of our build farm. But VSTool's only function is
>to set defaults for the IDE -- which is completely irrelevant to an
>unattended build! So for an official build-farm build, the only effect of
>running VSTool was the negative one of introducing intermittent failures.
>It can take an hour to rerun a full official build-farm build.
>2. VSTool was being run in a weird way, with '&&' being passed by
>autobuild.xml as a command argument.
>   - That relied on autobuild invoking commands through the shell.
>   autobuild-1.1 has recently started invoking commands directly
>   *without* using the shell, which in general is more robust and
>   secure. But that meant that '&&' and 'VSTool.exe' and its args were 
> being
>   passed to devenv as additional arguments. Of course devenv was 
> completely
>   nonplussed.
>   - autobuild.xml is not a scripting language. It has no way to
>   invoke VSTool conditionally. We couldn't run it only for interactive
>   developer builds.
>
>
> The *right* fix is for CMake to generate the .sln (etc.) files with the
> appropriate defaults already set.
>
> Until we get that, if your workflow involves autobuild configure followed
> by a Visual Studio IDE session, please run autobuild configure in a shell
> script that also runs VSTool with the arguments you've seen in previous
> versions of autobuild.xml.
>
>
>> Error 7 error LNK1181: cannot open input file
>> '..\llimagej2coj\Release\llimagej2coj.lib' C:\Users\Bill\P64\viewer64\bui
>> ld-vc120-32\newview\LINK secondlife-bin
>> Error 4 error C2039: 'page_zoom_factor' : is not a member of
>> 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind
>> ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef
>> Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such
>> file or directory C:\Users\Bill\P64\viewer64\bui
>> ld-vc120-32\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj
>>
>
> I jumped right in trying to build a 64-bit Windows viewer. Your mail
> prompted me to circle back and clean up the 32-bit Windows build of
> lindenlab/viewer64. I see these errors and am working on them. (I think
> I've already worked around the LLCEFLibSettings one.)
>
> Please stay tuned!
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Wed, Nov 23, 2016 at 12:24 PM, Nicky Perian 
wrote:

This is on a Release. The solution defaulted to Debug and I failed to
> notice.
> So, that raises the question; Why when autobuild source_environment is set
> to Release did it not follow through to the soultion?
>

There is a program called VSTool in indra/tools/vstool that has been used
to postprocess the .sln file generated by autobuild configure (running
CMake). We recently stopped running that implicitly, for a couple reasons:


   1. VSTool began failing intermittently on our build machines, impacting
   the reliability of our build farm. But VSTool's only function is to set
   defaults for the IDE -- which is completely irrelevant to an unattended
   build! So for an official build-farm build, the only effect of running
   VSTool was the negative one of introducing intermittent failures. It can
   take an hour to rerun a full official build-farm build.
   2. VSTool was being run in a weird way, with '&&' being passed by
   autobuild.xml as a command argument.
  - That relied on autobuild invoking commands through the shell.
  autobuild-1.1 has recently started invoking commands directly
  *without* using the shell, which in general is more robust and
  secure. But that meant that '&&' and 'VSTool.exe' and its args were being
  passed to devenv as additional arguments. Of course devenv was completely
  nonplussed.
  - autobuild.xml is not a scripting language. It has no way to invoke
  VSTool conditionally. We couldn't run it only for interactive developer
  builds.


The *right* fix is for CMake to generate the .sln (etc.) files with the
appropriate defaults already set.

Until we get that, if your workflow involves autobuild configure followed
by a Visual Studio IDE session, please run autobuild configure in a shell
script that also runs VSTool with the arguments you've seen in previous
versions of autobuild.xml.


> Error 7 error LNK1181: cannot open input file
> '..\llimagej2coj\Release\llimagej2coj.lib' C:\Users\Bill\P64\viewer64\bui
> ld-vc120-32\newview\LINK secondlife-bin
> Error 4 error C2039: 'page_zoom_factor' : is not a member of
> 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind
> ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef
> Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such
> file or directory C:\Users\Bill\P64\viewer64\bui
> ld-vc120-32\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj
>

I jumped right in trying to build a 64-bit Windows viewer. Your mail
prompted me to circle back and clean up the 32-bit Windows build of
lindenlab/viewer64. I see these errors and am working on them. (I think
I've already worked around the LLCEFLibSettings one.)

Please stay tuned!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

This is on a Release. The solution defaulted to Debug and I failed to
notice.
So, that raises the question; Why when autobuild source_environment is set
to Release did it not follow through to the soultion?

Error 7 error LNK1181: cannot open input file
'..\llimagej2coj\Release\llimagej2coj.lib'
C:\Users\Bill\P64\viewer64\build-vc120-32\newview\LINK secondlife-bin
Error 4 error C2039: 'page_zoom_factor' : is not a member of
'LLCEFLib::LLCEFLibSettings'
C:\Users\Bill\P64\viewer64\indra\media_plugins\cef\media_plugin_cef.cpp 504
1 media_plugin_cef
Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such file
or directory
C:\Users\Bill\P64\viewer64\build-vc120-32\packages\include\openjpeg\openjpeg.h
94 1 llimagej2coj


On Wed, Nov 23, 2016 at 10:06 AM, Nicky Perian 
wrote:

> Complete the record on opensource-dev.
>
> -- Forwarded message --
> From: Nicky Perian 
> Date: Wed, Nov 23, 2016 at 9:13 AM
> Subject: Re: 64 bit viewers build instructions
> To: Nat Goodspeed 
> Cc: "Oz Linden (Scott Lawrence)" 
>
>
> Thanks,
> I'm trying to build 32 bit windows first.
> These appear library related and since you are active in building them
> thought you should know. Likely that you already know but just in case 
>
> Error 11 error LNK1181: cannot open input file 'vorbisfile_static_d.lib'
> C:\Users\Bill\P64\viewer64\build-vc120\newview\LINK secondlife-bin
> Error 5 error LNK1181: cannot open input file
> 'libboost_coroutine-mt-gd.lib' C:\Users\Bill\P64\viewer64\bui
> ld-vc120\media_plugins\libvlc\LINK media_plugin_libvlc
> Error 9 error LNK1104: cannot open file 'libboost_coroutine-mt-gd.lib'
> C:\Users\Bill\P64\viewer64\build-vc120\llplugin\slplugin\LINK SLPlugin
> Error 10 error LNK1104: cannot open file 'exception_handler.lib'
> C:\Users\Bill\P64\viewer64\build-vc120\win_crash_logger\LINK
> windows-crash-logger
> Error 6 error C2039: 'page_zoom_factor' : is not a member of
> 'LLCEFLib::LLCEFLibSettings' C:\Users\Bill\P64\viewer64\ind
> ra\media_plugins\cef\media_plugin_cef.cpp 504 1 media_plugin_cef
> Error 1 error C1083: Cannot open include file: 'opj_stdint.h': No such
> file or directory C:\Users\Bill\P64\viewer64\bui
> ld-vc120\packages\include\openjpeg\openjpeg.h 94 1 llimagej2coj
>
>
> On Wed, Nov 23, 2016 at 8:43 AM, Nat Goodspeed  wrote:
>
>> On Wed, Nov 23, 2016 at 9:13 AM, Nat Goodspeed  wrote:
>>
>> On Wed, Nov 23, 2016 at 9:04 AM, Nicky Perian 
>>> wrote:
>>>
>>>
 For instance, the libraries for llphysicsextensions_stub need to be in

 http://automated-builds-secondlife-com.s3.amazonaws.com

 Instead of

 http://s3-proxy.lindenlab.com/private-builds-secondlife-com/
 ct2/467/985/

>>>
>>> Sorry! I should be able to get you a new public build of
>>> llphysicsextensions_stub.
>>>
>>
>> https://bitbucket.org/lindenlab/viewer64/commits/4838e2cf369
>> 48f911b072a018f68f1be8c54eeba
>>
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges