On 24/05/2016 04:33, Marvin Humphrey wrote:
These compiler flags must be reused when compiling code for host language
bindings. A good example is `-m32` to create 32-bit binaries on 64-bit
systems. Other examples are '-mms-bitfields` (used by some Windows Perls)
and flags concerning data alignment.
So we'd have scan the host language C flags and make sure to reuse all flags
that cause incompatible code to be generated. Since there is no conclusive
list of all these flags, this approach is error-prone and will probably need
occasional updates. I'm not saying it can't be done, but for now, I'd prefer
to simply use all the compiler flags proposed by the host language. Maybe it
would make more sense to have a blacklist of flags that are safe to remove?
My guess, which admittedly doesn't have a lot to back it up, is that although
there is an open set of potentially incompatible flags, there aren't that many
that we wouldn't find out about right away and be able to fix via
whitelisting.
Probably. My only concern is that some flags might result in subtle
incompatibilities that don't cause problems with our current code base, but
might do so later. Such cases will be extremely hard to debug.
I think adding support for multiple parcels with separate binaries per
parcel isn't much harder. Instead of building a binary with test and
non-test code, we'd build a binary that contains only the test code. This
should have other uses besides testing. OTOH, having separate binaries
places some restrictions on the test code.
That may be, but as discussed before,
(<http://markmail.org/message/tmn4jb3yveftumu5>) Clownfish parcels were
intended to represent atomic units of installation in order to facilitate
versioning of dependencies. Having multiple parcels installed together
complicates the mechanisms to handle resolving compatible versions and advise
what and when to upgrade.
My plan is to create separate .xs and .so files for every parcel, each having
their own version. So in theory, every parcel could also be installed separately.
Nick
