Bug 72231

Created attachment 114869 [details] Patch

I still don't like this idiom. I don't see the upside to it, and I don't know how to avoid breaking it in future.

(In reply to comment #2) > I still don't like this idiom. I don't see the upside to it, and I don't know how to avoid breaking it in future. What are the options? I see: 1) The project will only support building JSC as shared lib if you use port & platform specific export files. 2) We add the export macro to _classes_, resulting in slightly more exported symbols that aaabsolutely necessary. (easier to maintain) 3) We add the export macro to classes and individual functions (like in attachment 114869 [details]). (harder to maintain, but closer to option 1) I would prefer option number 2, but the decision lies probably in the hands of the JSC folks :)

(In reply to comment #3) > (In reply to comment #2) > > I still don't like this idiom. I don't see the upside to it, and I don't know how to avoid breaking it in future. > > What are the options? > > I see: > > 1) The project will only support building JSC as shared lib if you use port & platform specific export files. > 2) We add the export macro to _classes_, resulting in slightly more exported symbols that aaabsolutely necessary. (easier to maintain) > 3) We add the export macro to classes and individual functions (like in attachment 114869 [details]). (harder to maintain, but closer to option 1) > > I would prefer option number 2, but the decision lies probably in the hands of the JSC folks :) I'd obviously prefer number 2 as well, and IMHO it's much less maintenance work, but the JSC folks did not want people to think they can, or be able to, use the exported classes as public API, so I have been told that if we're to do it it has to be per-symbol (as the current approach is). In a few cases, though, we actually do have to export the whole class when WebCore, etc. needs access to things like the viable that are only exported when you export the class, so you may see that from time to time. I only do that when it's necessary to get it linking, though.

(In reply to comment #2) > I still don't like this idiom. I don't see the upside to it, and I don't know how to avoid breaking it in future. I'm not sure I understand. If all the ports building JSCore shared use this approach, which is the necessary end result of this process, I don't see how it can break for any port because for any common symbol change, you'll need to add the export macro to get it linking, and once you do that, all ports get updated at the same time. For port-specific stuff, the port that needs it adds it, and the rest of the ports ignore it, so again no breakage AFAICT. In contrast, right now, it's easy to add an export symbol to only one port and break the others, and any new port that wants to build JSCore shared must craft their own export symbol files and commit to maintaining them. To be honest, I don't see what the upside to doing it that way is, and it was my understanding that it was decided to do things this way before multiple ports were in the tree.

This bug is superseded by work to automate the adding of header macros.