| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
hi, |
| 5 |
|
| 6 |
im currently changing the boost build process so users who require boost |
| 7 |
only as a dependency of another app only get release versions, |
| 8 |
developers would get debug versions as well (another ~40-90MB varying |
| 9 |
from system to system it seems) USE=debug is easy choice there |
| 10 |
|
| 11 |
i intended to then utilize USE=threads to add the multi threaded |
| 12 |
versions of libs and single by default or -threads, here comes my |
| 13 |
question, the build process allows for <threading>multi |
| 14 |
<threading>single and <threading>multi/single, building only |
| 15 |
multithreaded versions, only single threaded versions, or both. |
| 16 |
|
| 17 |
do the three choices make sense or are we better off with only building |
| 18 |
single threaded versions and on USE=threads (to use what already exists |
| 19 |
rather then making a new USE flag) then build single/multi |
| 20 |
else id need possibly two awkwardly named USE flags (and suggestions for |
| 21 |
names (using threads and threadsonly, similar to nptl?) |
| 22 |
|
| 23 |
similarly it allows for linking to static, dynamic or both |
| 24 |
should the static USE flags be used to change from dynamic (proposed |
| 25 |
default behaviour) to static, or ADD so build process uses |
| 26 |
<runtime-link>static/dynamic |
| 27 |
(using static and staticonly if 3 states are needed?) |
| 28 |
|
| 29 |
i guess i could get away with only 2 new USE flags (threadsonly and |
| 30 |
staticonly) |
| 31 |
ok, do we need them, shouldnt we have them? |
| 32 |
|
| 33 |
any ideas, suggestion, critcism welcome |
| 34 |
|
| 35 |
Daniel |
| 36 |
-----BEGIN PGP SIGNATURE----- |
| 37 |
Version: GnuPG v1.4.0 (GNU/Linux) |
| 38 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 39 |
|
| 40 |
iD8DBQFCYZ8fUpKYMelfdYERAkDrAJwNsYnyDH03J9VmS9Ax7vbj6lmaJACfd+nd |
| 41 |
64dwN4WTTw2AudeKOJETgpo= |
| 42 |
=JFaH |
| 43 |
-----END PGP SIGNATURE----- |
| 44 |
-- |
| 45 |
gentoo-dev@g.o mailing list |
Archives