___
one thing may already be said, there is no increase in compile-time.
there are two or three intra-dependencies within boost libraries from ~15 libraries available.
- they compile that fast it does not hurt.

Although I'm impressed, this is too hot for me - no way (or, time ) I'm going to figure out which parts of the boost distribution are needed by the various packages that depend on it. Could you please mask it for the not-so-experimental guys? _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

question, what is the pros over the current way?
also, if current state is one block, why not use one build with useflags?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

DaggyStyle
I think I have stated why it is useful in the first post already. most of the libraries are not used.

talking about system packages, right now, paludis, and when I start on java-config that one, too, would depend on the full blown boost package.
that is self-explaining: silly for that it uses only a minimal subset.

like I said already, I just want to show its use to split. I do not say that it has to be this way.
so, another way is to add useflags to the gentoo boost package.
though, instead of adding useflags, I could think of another idea.

sorry, you post was too long and I've lost concentration.
in that case,why not use one ebuild with multiple use flags?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

great idea. i think it's only natural for gentoo to split up big multi-feature packages like that.

i wish we had the same thing for openoffice (it actually distributes its apps in separate tarballs, which suggests that upstream is supporting such builds)._________________~amd64
shrink your /usr/portage with squashfs+aufs

# FIXME: this is not triggered!
# Remove (unversioned) symlinks
# And check for what we remove to catch bugs
# got a better idea how to do it? tell me!
for f in $(ls -1 ${LIBRARY_TARGETS} | grep -v "${MAJOR_PV}") ; do
echo "DEBUG: $f"

if [ ! -h "${f}" ] ; then
eerror "Ups, tried to remove '${f}' which is a a real file instead of a symlink"
die "slotting/naming of the libs broken!"
fi

sorry, you post was too long and I've lost concentration.
in that case,why not use one ebuild with multiple use flags?

You can always do that later. Just wrap all the boost-* ebuilds into a boost-meta ebuild and add lots of use flags if that's your call. Not that your are going to gain anything doing that, though. The modular approach has only advantages, just like in kde or qt to name a couple of examples. That way, other ebuilds can depend only on the needed split package, instead of depending upon the whole monster that boost is._________________Gentoo Handbook | My website

sorry, you post was too long and I've lost concentration.
in that case,why not use one ebuild with multiple use flags?

You can always do that later. Just wrap all the boost-* ebuilds into a boost-meta ebuild and add lots of use flags if that's your call.

This would make much more sense and be easier to maintain. For instance, poppler (and some others which I forgot now) have been changed from split ebuild into an ebuild with useflag.

Quote:

Not that your are going to gain anything doing that, though.

For instance, you gain that an

Code:

emerge -f @world

(e.g. with the trickyfetch script) would be much faster, because there is no need to checksum the same tarball everytime. Also maintenance (revbump) is much easier, since one revbump changes everything and you do not have the problem that you need to check whether different versions are compatible (or even have to block each other which can cause unnecessary headache for the user).

Quote:

The modular approach has only advantages, just like in kde or qt to name a couple of examples.

I can see only disadvantages. It only makes sense if there are reasons to recompile rather often only some of the split ebuilds and not any others. For a mega-project like kde this makes sense (revdep-rebuild), for qt the approach is already doubtfully.

Quote:

That way, other ebuilds can depend only on the needed split package, instead of depending upon the whole monster that boost is.

Which is a completely meaningless argument now that portage has USE-dependencies.

(e.g. with the trickyfetch script) would be much faster, because there is no need to checksum the same tarball everytime.

doing multiple checksum and portage idle my split-boost is 1/3 of merge time compared to full boost. what do I miss in your statement?

mv wrote:

Also maintenance (revbump) is much easier, since one revbump changes everything and you do not have the problem that you need to check whether different versions are compatible (or even have to block each other which can cause unnecessary headache for the user)

I still have SLOTs and instead of one ebuild I have one eclass. revbump causes one library to remerge over complete boost. hmm ....

mv wrote:

I can see only disadvantages. It only makes sense if there are reasons to recompile rather often only some of the split ebuilds and not any others. ... for qt the approach is already doubtfully.

to the latter, you must have a high-end cpu. I get sick each time I have to update qt4. I am glad it is split. to the former, yes, I use just some. and the general desktop will. remember, I just have to maintain one eclass instead of one ebuild. no difference in maintenance.

mv wrote:

i92guboj wrote:

That way, other ebuilds can depend only on the needed split package, instead of depending upon the whole monster that boost is.

Which is a completely meaningless argument now that portage has USE-dependencies.

o ha, try that on a not so brand-new hardware.
just have a look at bjam analysing the headers on install stage. if you got that time, you can do it the other way around, too. _________________boost|select libs to build|slotable|python-buildid

(e.g. with the trickyfetch script) would be much faster, because there is no need to checksum the same tarball everytime.

doing multiple checksum and portage idle my split-boost is 1/3 of merge time compared to full boost. what do I miss in your statement?

You mean emerging the related split ebuilds is three times faster than emerging one monolithic ebuild (with the corresponding USE-flags set, of course)? In this case, I would say that the build system of the monolithic ebuild is broken.
However, it is more likely that something in your measurement is false (e.g. you have used ccache and did not empty it before emerging the split ebuilds or something similar).

Quote:

I still have SLOTs and instead of one ebuild I have one eclass. revbump causes one library to remerge over complete boost. hmm ....

So you install redundant identical data in different slots. And the eselect of course changes slots of every split ebuild simultaneously so that it makes absolutely no sense to have one of the split ebuild installed in one version but not in another. Once again: What is the advantage of not installing all in one ebuild?

Quote:

mv wrote:

I can see only disadvantages. It only makes sense if there are reasons to recompile rather often only some of the split ebuilds and not any others. ... for qt the approach is already doubtfully.

to the latter, you must have a high-end cpu. I get sick each time I have to update qt4. I am glad it is split.

For upgrading qt, it would need the same (actually even less) time if qt were not split (but of course only those parts corresponding to the USE-flags are compiled). The only case where you see a difference is if you have to reemerge the same version of a split ebuild but not the other installed ones - this usually can only happen during revdep-rebuild, if only one of the split ebuilds has a dependency on some library but the others not. But how often does this really occur?

Quote:

remember, I just have to maintain one eclass instead of one ebuild. no difference in maintenance.

There will be enormous difference if you want to avoid installing redundant data. If you do not want to avoid this, split ebuild makes no sense - USE-flags-ebuild is preferrable.

Quote:

mv wrote:

i92guboj wrote:

That way, other ebuilds can depend only on the needed split package, instead of depending upon the whole monster that boost is.

Which is a completely meaningless argument now that portage has USE-dependencies.

o ha, try that on a not so brand-new hardware.

What are you talking about? Do you seriously believe that portage needs considerable more CPU-time to track USE-dependencies instead of a split ebuild?

Quote:

just have a look at bjam analysing the headers on install stage. if you got that time, you can do it the other way around, too.

I do not understand how this is related with the question of whether split ebuilds or a monolithic ebuild with USE-flags (to determine the parts to be built) is preferrable.

'inherit boost-utils' - add this line to src_configure before configure ; it checks for the minimum version required!

You might want to rephrase that, in the current form it sounds (to me at least) like the inherit call should be added in src_configure, I had to read it three times until I realized you meant the following line. Fortunately I couldn't believe anyone would really call inherit inside a function

and to most of the other things I states my pov already. I know the advantages and disadvantages of various ways. how it is done it does not really matter but for the headers being DEPEND or RDEPEND, then. just thinking about intranet distribution. and yes, we have the bandwidth it does not really matter. so we may turn around and round and ... in the end it is how the maintainers want it to be.

just one final thing.

mv wrote:

There will be enormous difference if you want to avoid installing redundant data. If you do not want to avoid this, split ebuild makes no sense - USE-flags-ebuild is preferrable.

that you should show me. at the moment I avoid more than the other way.

There will be enormous difference if you want to avoid installing redundant data. If you do not want to avoid this, split ebuild makes no sense - USE-flags-ebuild is preferrable.

that you should show me.

Let us say you have boost-filesystem:1.41 and boost-filesystem:1.42 but actually the filesystem-related code did not change in the upgrade boost-1.41 ->boost-1.42 (i.e. only other parts of boost were changed). Then you could omit boost-filesystem:1.42 and depend instead on boost-filesystem:1.41: This way, the user would neither have to upgrade to boost-filesystem:1.42 nor would he have to install boost-filesystem:1.42 redundantly if he wants to have both slots. Of course, eselect-boost would need to be smart enough to set correct symlinks.
If ebuilds are really maintained this way, this is a lot of work for the maintainer, but it really saves compilation time for the user: The maintainer has to check for every upgrade which packages really changed. Moreover, it would be sane to change the boost-filesystem:1.41 ebuild (without revbump) for the upgrade to use the tarball of boost-1.42: This way, the user who wants only the most current boost would not have to keep the old boost-1.41 tarball around (or download it again) when he needs to re-emerge boost-filesystem:1.41.

Quote:

at the moment I avoid more than the other way.

I do not see anything which you avoid in the moment - I mean compared to ebuild with USE-flags, of course. Just in case that this was a misunderstanding: I do not argue, of course, that a split ebuild has advantages over a monolithic ebuild without USE-flags. However, a monolithic ebuild with USE-flags has even more advantages.
This is what happened e.g. to poppler: First, it was split, but then the maintainer decided that it is more reasonable to have a monolothic ebuild with USE-flags instead and to have USE-dependencies. I can understand this both, from a user perspective (concerning problems with upgrade blockers and the mentioned repeated checksumming) as well as from the maintainer's perspective (you have to bump all ebuilds, and unless you do the mentioned work with comparing versions for every bump, there is no real point in having split ebuilds). Of course, this is only possible since USE-dependencies are available - otherwise it would be a nightmare for users.
In my opinion there is just a few cases where - in the presence of USE-dependencies - it really makes sense to have split ebuilds: This is mainly if a package has many split ebuilds which in turn need to have separate USE-flags or are such that it is not an exception that a user wants to install or uninstall one of the split ebuilds independently from the others. A collection of programs like KDE is an example where both cases apply. A collection of libraries like boost/qt/poppler does not belong to this class in my opinion, since most users will install these only by means of dependencies, and these are not likely to change frequently.

well, you talk about my implementation. that is just not the point in this thread. what I want to show is what can be improved. full stop.
the implementation is up to the maintainer alone and his/her liking.

...
-----------------------------------------------------------------------------
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
-----------------------------------------------------------------------------
* Boost (1.34.0 or higher) <http://www.boost.org>
Boost C++ Libraries
Required by several critical KDEPIM apps.
* The Boost Topological_sort header <http://www.boost.org/>
topological_sort.hpp (part of Boost_graph)
Necessary to build kleopatra

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Boost_INCLUDE_DIR (ADVANCED)
used as include directory in directory /var/tmp/portage/kde-base/akonadi-4.4.1/work/akonadi-4.4.1/akonadi/kcal
used as include directory in directory /var/tmp/portage/kde-base/akonadi-4.4.1/work/akonadi-4.4.1/akonadi/akonadi_next
used as include directory in directory /var/tmp/portage/kde-base/akonadi-4.4.1/work/akonadi-4.4.1/akonadiconsole