You're thinking along the right lines, but a separate metaproj would be
completely incompatible with the way we build things now.
What we had an MS was multiple perl ABIs:
5.004
5.005
5.005-threads
5.6
5.6-threads
Actually, we might have made threads the default in 5.6, in which case, that
last one didn't exist. But the point is that when we built a given module
for multiple ABIs, just we do today with efsdeploy, thread support was just
another ABI.
If you were to use a separate metaproj for this, then you would not be able
to use a tool like efsdeploy to build a single product for multiple ABIs,
since the build won't be contained in a single release.
The model for multiple perl ABI and multiple C++ ABIs is the same. For any
given release of software, we make it available as a single release, with
multiple installs (one per platform) each of which contains multiple ABI
builds. If you look at the namespace today, this is how things are managed.
/efs/dist/$metaproj/$project/$release/.exec/$platform/$abi/....
That is the structure of the namespace for ALL of the various $abi types we
create builds for: C++, Perl, and eventually other languages.
To see why your idea doesn't work, consider how you would support, say gcc
4.5. You don't want to create /efs/dist/fsf-gcc450, right? You simply
start building releases that include builds for the new C++ ABI.
On Tue, Jul 20, 2010 at 9:49 AM, jerry gay <[email protected]> wrote:
> On Tue, Jul 20, 2010 at 5:27 AM, Phillip Moore
> <[email protected]> wrote:
> > I recently stopped building perl with threads support, based largely on
> > Jerry's feedback that the perl community as a whole would prefer people
> not
> > use the threads support.
> > Well, that might end up being an expensive decision, and here's why. If
> we
> > end up with a request from our users for a threads-enabled perl. we can
> > always create a special build for them (say, in perl5/core-threads, or
> > something similar). However, as soon as you do that, in all likely hood
> > many of the existing compiled XS modules will NOT work with both builds
> of
> > perl5. That is, if you have perl5/core/5.10.1 and
> > perl5/core-threads/5.10.1, then modules compiled with one may not work
> > (perhaps at all) with the other.
> > That means you have introduced a new binary ABI, and that means you have
> to
> > introduce two "compiler" definitions for perl 5.10.1, and build
> everything
> > for 5.10 twice. This what we had to do back at MS, for perl5.6. We had
> > both "5.6" and "5.6-threads" in the namespace, next to 5.004, 5.005 and
> > 5.005-threads, too.
> > I originally kept the builds separate, since I found that the perl
> benchmark
> > suite ran 20% slower across the board when threads were enabled. While
> I
> > have not personally done the benchmarks, I recall reading somewhere that
> > this performance penalty was addressed in 5.8 and beyond.
> > Therefore, in order to simplify the way we build perl modules, I only
> wanted
> > ONE build of each core release, and ONE ABI to worry about. Therefore,
> I
> > built perl5/core with threads by default.
> > This raises and interesting issue, and shows how limited, in practice,
> > sharing of binaries in EFS will be. We have to make these decisions
> based
> > on what will work for OUR users and OUR user community. Other sites may
> > very well want to make different decisions, and thus will want different
> > builds of perl and friends.
> > I think we need to give this decision some more thought. I am very
> > concerned about the cost of maintaining both non-threaded and threaded
> perl
> > in EFS. Sadly, I knew who used the threads API at MS; I have no idea
> who
> > may or may not be using it here, and trying to gather that information
> will
> > be exceptionally difficult. We can post a messages to the efsperl
> mailing
> > list (which has seen no traffic in over a year), but we can't count on
> the
> > responses being a representative statistical sampling of our user
> community.
> > Bear in mind that for perl5.10, in /efs/dist/perl5, we already built with
> > threads, so we can't really implement this internally until we deploy
> 5.12
> > or later releases. IOW, we're stuck with perl5.10 with threads
> internally.
> >
>
> back in ms, did you also have perl5/<some-module>/ and
> perl5/<some-module-threads>/ when necessary, to deal with the abi?
> that seems... messy, as the project namespace gets polluted fast, and
> it's not easy to see what threaded vs non-threaded modules are
> available.
>
> my first suggestion is to define a separate metaproject, say
> perl5-threads/ and have the EFS::Perl::Depends code be configured to
> search multiple metaprojects for modules. for example, a user wishing
> to use Try-Tiny-0.06 in a piece of code using perl5threads/core would
> write
>
> #!/efs/dist/perl5-threads/5.10/.../bin/perl
> # this isn't the real shebang, just clarifying user wants perl5-threads
> perl
> use EFS::Perl::Depends qw( Try-Tiny/0.06 );
>
> and the module would first search the perl5-threads/ metaproject, and
> when Try-Tiny isn't found, search the perl5/ metaproject. this would
> allow us to compile releases of perl5 modules only when required for
> another metaproject. so, for example, Object-InsideOut-3.67 would be
> compiled for both perl5-threads/ and perl5/.
>
> #!/efs/dist/perl5-threads/5.10/.../bin/perl
> use EFS::Perl::Depends qw(Object-InsideOut/3.67 );
>
> would load perl5-threads/Object-InsideOut/3.67, since it's been
> compiled in both metaprojects. if a specific metaproject is specified
> in the EFS::Perl::Depends use statement, that mpr will be loaded no
> matter what, so
>
> use EFS::Perl::Depends qw( perl5/Object-InsideOut/3.67 );
>
> will always load perl5's Object::InsideOut, even if the user is using
> perl5-threads/core.
>
> obviously, we'll have to determine at packaging time whether a module
> needs to be packaged for multiple metaprojects, but i think that we
> can build a couple small utilities to help us make that determination
> (the simplest case being something that greps the tarball for
> 'threads' and lets the packager know to look more closely). we'll
> also have to clearly document this, as well as exactly how
> EFS::Perl::Depends is configured to search the metaproj namespaces,
> and how that can be modified. also, we'll need to figure out how
> EFS::Perl::Depends is found in the first place... is it packaged in
> each perl5- metaproj? probably.
>
> additionally, we might consider metaproj aliasing, so our metaproj
> names may be more descriptive, and one is selected to be the default.
> in this scenario, perl5/ could be a 'metaprojalias' to either
> perl5-nonthreads/ or perl5-threads/ or some other perl5-
> configuration.
>
> i'm throwing a lot out here, but this is a large topic and full of
> different levels of complexity. no doubt i've missed something here,
> but there is no perfect solution, it's a matter of trade-offs.
> thoughts?
>
> ~jerry
> _______________________________________________
> EFS-dev mailing list
> [email protected]
> http://mailman.openefs.org/mailman/listinfo/efs-dev
>
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
