On Jan 16, 2018, at 1:40 PM, Chuck Atkins
mailto:chuck.atk...@kitware.com>> wrote:
Perhaps one can split out the .cpp and build changes somehow.
Good idea. It's easy enough to split and without the autoconf changes the
existing behavior will still be preserved so the other two builds can stil
>
> Perhaps one can split out the .cpp and build changes somehow.
>
Good idea. It's easy enough to split and without the autoconf changes the
existing behavior will still be preserved so the other two builds can still
work as they normally do, they just won't have the builtin-swr feature.
- Chuc
On 16 January 2018 at 17:57, Eric Engestrom wrote:
> On Tuesday, 2018-01-16 10:36:49 -0500, Chuck Atkins wrote:
>> When only a single SWR architecture is being used, this allows that
>> architecture to be builtin rather than as a separate libswrARCH.so that
>> gets loaded via dlopen. Since there
On Tuesday, 2018-01-16 10:36:49 -0500, Chuck Atkins wrote:
> When only a single SWR architecture is being used, this allows that
> architecture to be builtin rather than as a separate libswrARCH.so that
> gets loaded via dlopen. Since there are now several different code
> paths for each detected
When only a single SWR architecture is being used, this allows that
architecture to be builtin rather than as a separate libswrARCH.so that
gets loaded via dlopen. Since there are now several different code
paths for each detected CPU architecture, the log output is also
adjusted to convey where t
