Volunteer for a workshop on "setting up your own buildbot/buildslave"?
raimue at macports.org
Wed Nov 11 05:05:40 PST 2015
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
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:
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?
More information about the macports-dev