Restructuration of Boost.SIMD

[Joel FALCOU]

Hi all,

Boost.SIMD is planned this year to be proposed to Boost for review. To
prepare this, we need to think about how to make changes to its file
structure so it can be both coherent with Boost standards and how we
want to use it with NT2 and other proprietary softwares.

The main issue now is the fact that Boost.SIMD use a loose module
approach with cmake configure-time generated headers. I want to
propose the following :

- Convert Boost.SIMD to a classical, flat, boost folder structure

- Pregenerate all inclusion headers once

- Provide the header generator as a separate cmake script callable for
developpers

- Change the way files are ordered internally :

* boost/simd/<arch-familly>/<arch>/<component>/<file>

instead of :

* boost/simd/<component>/<arch-familly>/<arch>/<file>

This change will make addition of external moduel for different
arch-familly or different arch easier and compatible wit NT2/other
library usage.

- Once done, we can separate Boost.SIMD from NT2 and have NT2 use
Boost.SIMD as a regular git-submodule.

What do you think of this ?

[Mathias Gaunard]

On 26/01/2015 20:56, Joel FALCOU wrote:
> Hi all,
>
> Boost.SIMD is planned this year to be proposed to Boost for review. To
> prepare this, we need to think about how to make changes to its file
> structure so it can be both coherent with Boost standards and how we
> want to use it with NT2 and other proprietary softwares.
>
> The main issue now is the fact that Boost.SIMD use a loose module
> approach with cmake configure-time generated headers. I want to
> propose the following :
>
> - Convert Boost.SIMD to a classical, flat, boost folder structure
>
> - Pregenerate all inclusion headers once

Anyone that wants to use one or several third-party external modules
will still need to regenerate them.

>
> - Provide the header generator as a separate cmake script callable for
> developpers
>
> - Change the way files are ordered internally :
>
> * boost/simd/<arch-familly>/<arch>/<component>/<file>
>
> instead of :
>
> * boost/simd/<component>/<arch-familly>/<arch>/<file>
>
> This change will make addition of external moduel for different
> arch-familly or different arch easier and compatible wit NT2/other
> library usage.

Why not, it's just a matter of how you want to group files. However this
would require more complicated logic than what the existing script
already does, unless you want to get rid of components altogether.

> - Once done, we can separate Boost.SIMD from NT2 and have NT2 use
> Boost.SIMD as a regular git-submodule.

There is no requirement to put all existing boost.simd modules into one
for Boost inclusion. Boost supports libraries split as several modules
just fine.

The only thing that's really required for Boost inclusion is Jamfiles.

Pregenerating headers is probably a useful thing to do for usability. It
can also makes it much simpler to write the Jamfiles.

[Joel FALCOU]

> Anyone that wants to use one or several third-party external modules
> will still need to regenerate them.

Yes that's still a thing to do but we can actually have that handled
internally.

> Why not, it's just a matter of how you want to group files. However this
> would require more complicated logic than what the existing script
> already does, unless you want to get rid of components altogether.

<component> may be superfluous indeed

> There is no requirement to put all existing boost.simd modules into one
> for Boost inclusion. Boost supports libraries split as several modules
> just fine.

Sure. Was more thinking about movign it outside nt2.git mostly.

> The only thing that's really required for Boost inclusion is Jamfiles.

Yes :s

> Pregenerating headers is probably a useful thing to do for usability. It
> can also makes it much simpler to write the Jamfiles.

A lot of recent users got bit by that. cloned github, tried to use
makefiles without cmaking once, got bitten.

[Joel FALCOU]

On 02/02/2015 11:33, Mathias Gaunard wrote:
> On 26/01/2015 20:56, Joel FALCOU wrote:
>> Hi all,
>>
>> Boost.SIMD is planned this year to be proposed to Boost for review. To
>> prepare this, we need to think about how to make changes to its file
>> structure so it can be both coherent with Boost standards and how we
>> want to use it with NT2 and other proprietary softwares.
>>
>> The main issue now is the fact that Boost.SIMD use a loose module
>> approach with cmake configure-time generated headers. I want to
>> propose the following :
>>
>> - Convert Boost.SIMD to a classical, flat, boost folder structure
>>
>> - Pregenerate all inclusion headers once
>
> Anyone that wants to use one or several third-party external modules
> will still need to regenerate them.

I thougth about this again. This can just be a phae of installing said
external modules.