Volunteer for a workshop on "setting up your own buildbot/buildslave"?

[Rainer Müller]

On 2015-11-11 12:17, Ryan Schmidt wrote:
> 
> On Nov 10, 2015, at 12:21 PM, Joshua Root wrote:
> 
>> On 2015-11-11 00:26 , Mojca Miklavec wrote:
>>> If we start including macosx_deployment_target, macosx_sdk,
>>> prefix, applications_dir, frameworks_dir, ... we'll sooner or
>>> later end up in an exponential mess
>> 
>> These are the type of settings that are associated with an entire
>> source in archive_sites.conf, because all the archives from a given
>> source will have them set the same. If any of these settings for a
>> source don't match the ones used locally, the source is simply not
>> used. Putting cxx_stdlib in here as well would be a good fit.
> 
> That sounds reasonable, except that it would create duplicate
> archives (one "libstdcxx", one "libcxx") for noarch ports that
> definitely don't use any C++ library, wouldn't it?

Technically you are correct, an archive for a noarch port would be
identical regardless of the value of the cxx_stdlib option.

However, an archive site can only host archives with one configuration
set (prefix, applications_dir, ...). If we add cxx_stdlib there, either
all ports will use libstdc++ or all will use libc++.

> Wouldn't it also have been reasonable to have the os name and version
> as part of those settings? Why was that put into the filename
> instead?

Historically evolved? You usually do not want to fetch archives for
anything else than the current OS, so it is implicit.

We could also host the packages in subdirectories:
  .../${os.platform}/${os.major}/${build_arch}/*.tbz2
However, you would have to replicate this structure on fetch. It would
not make much difference whether this is in the path or in the filename.

> If we used this strategy, what hypothetical base URL would we use for
> libc++ packages on older systems? Would you define a second hostname
> in addition to packages.macports.org (inconvenient for mirrors), or
> would you create a subdirectory on that server?

Is your intention to build all packages twice, for both libc++ and
libstdc++? Is that even worth the effort?

Rainer