On 3/16/16, 1:51 PM, "Randolph M. Fritz" > wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
On Wed, Mar 16, 2016 at 12:54 PM, Guglielmetti, Robert <
robert.guglielme...@nrel.gov> wrote:
> Because it's so fuc*ing big.
>
When 2 GB RAM is standard for a low-end syst
Forking this into a new thread.
Am 2016-03-16 17:00, schrieb Rob Guglielmetti:
Same for testing; any tests for scons should probably be "ported" to
CMake and vice versa, assuming each testing framework has the the
other's ability...
That sounds like a lot of duplicate work...
Wouldn't it make
On 3/14/16, 8:26 PM, "Georg Mischler" wrote:
>But now I'll fetch the Windows libraries and the Qt5 tool.
>Has it actually ever been built on a non-Windows system?
Yeah. Way it works on unix is that qtrvu is called when you specify qt as
the output device in a rvu call:
rvu -o qt foo.oct
Tha
But the Radiance source is 3 MB, and Qt 5.6 for Windows is 836 MB. Radiance's
dependency list is short and small excepting the Qt requirement for qtrvu. It's
kinda nice. Maybe I'm making too much of this. I dunno.
On 3/16/16, 2:00 PM, "Randolph M. Fritz"
mailto:rmfri...@gmail.com>> wrote:
On 3
I don't think I'm gonna touch (or even try to understand) that driver
business. On Windows, preview renderers have traditionally always been
native reimplementations of rvu. Rob is free to change that, of
course...
-schorsch
Am 2016-03-16 21:43, schrieb Gregory J. Ward:
While rvu can (and hi
Well, it took me a while to figure out where the rabbit went, but it looks like
the folks at Kitware did build the "qt" driver in the standard way, linking it
with rvu albeit in another directory. I don't remember the conversation on
this, but it might have something to do with separability and
Am 2016-03-16 21:00, schrieb Randolph M. Fritz:
On 3/16/16, 1:51 PM, "Randolph M. Fritz"
mailto:rmfri...@gmail.com>> wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty
common.
On Wed, Mar 16, 2016 at 12:54 PM, Guglielmetti, Robert
wrote:
Because it's so fuc*ing big.
I think the pipe approach is a good one. A separation of UI and
computational functions is probably a good way to organize the code, when
it is possible.
___
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailma
I see what you mean. Even as binaries those are a hefty dependency.
___
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
Hi All,
It would be great if you guys could pool resources and decide which tool to
advance as the standard Radiance picture viewer for Windows. Then, we could
re-introduce it to the source tree and keep it up to date in future releases.
Likewise for rvu, which I would prefer to be a driver c
The criteria I would apply are:
- Which framework is easiest to install for end users?
Or maybe better: Which is most likely to be already installed on the
system of the average Radiance user, even when not part of the
currently running build system?
* On unix
* on Mac (as far as differ
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
--
Randolph M. Fritz, Lighting Design and Simulation
+1 206 659-8617 || rmfri...@gmail.com
On Wed, Mar 16, 2016 at 9:00 AM, Rob Guglielmetti <
rob.guglielme...@gmail.com> wrote:
> Agreed, this is awesome, even if it means
rim_shot()
On 3/16/16, 3:20 PM, "Gregory J. Ward" wrote:
>You couldn't cmake me touch that one with a 10-foot python.
>
>> From: Georg Mischler
>> Subject: [Radiance-dev] Test suite design
>> Date: March 16, 2016 2:02:11 PM PDT
>>
>> Forking this into a new thread.
>>
>> Am 2016-03-16 17:00,
Because it's so fuc*ing big.
On 3/16/16, 1:51 PM, "Randolph M. Fritz"
mailto:rmfri...@gmail.com>> wrote:
Why is Qt an especially onerous dependency? It's LGPL and pretty common.
___
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www
14 matches
Mail list logo
