IssueTracker

I just spent quite a while trying to tweak the V8 component build as part of https://crbug.com/368047728. While doing so, I ran into several things that don't seem to be working correctly. I tried fixing several of them in the process of fixing my bug, but the fixes seemed to end up with other things broken. Issues were most prevalent in Windows builds, due to dllimport/export semantics.

Things I noticed, in rough order of how confident I am about the issue:

1. It's possible to define both the USING_ and BUILDING_ macros for a given component. include/v8config.h has a check for this, but it's very easy for it to happen when tweaking the build. In at least one case (src/utils/v8dll-main.cc) the problem is just ignored by #undef-ing one of the macros.
2. Most components don't have this check; if you add an analogous check to e.g. include/libplatform/libplatform-export.h (as below), it finds errors.

#if defined(BUILDING_V8_PLATFORM_SHARED) && (USING_V8_PLATFORM_SHARED)
#error "Inconsistent build state"
#endif

3. The order of includes and defines can be wrong: the check in wasm/c-api.h never goes off because the build system sets BUILDING_V8_SHARED_PRIVATE, but not BUILDING_V8_SHARED. This means that LIBWASM_STATIC is always set to 1, so I think this is never compiled as a shared library.
   1. This should be fixable by #include "include/v8config.h before the check, since it will promote the SHARED_PRIVATE macro to the _SHARED one. It's already included in the file after the check via v8-isolate.h, but that's after the check. Note that the check needs to go before wasm.hh is included, because it uses the LIBWASM_STATIC define.
   2. It also seems impossible to compile wasm.hh with WASM_API_EXTERN set to __declspec(dllexport), which seems wrong; probably, this check should also include a condition for setting that.
4. It's unclear which component files are expected to belong to, which leads to inconsistent annotations. For example, v8-platform.h uses the V8_EXPORT macro instead of V8_PLATFORM_EXPORT. Not only is this unintuitive to a reader, but this means that when the file is included in platform code (e.g. the v8_libplatform target, the USING_V8_SHARED macro needs to be set, which doesn't seem to be the case. It's possible that switching the macros would result in the opposite problem (including the file would require defining USING_V8_PLATFORM_SHARED).