I submitted this CL on Friday and it is now breaking on Windows:https://codereview.chromium.org/986503002/Here is the build output:Is Windows using a GYP or GN build? I think it is GYP since GN is only recommended for Linux.
I added some ChromeOS-conditional wrappers to metrics.gypi and metrics/BUILD.gn.However, I'm getting compile errors in unrelated code when building the "all" target, e.g.../../mojo/shell/application_manager_apptest_driver.cc:85:9: error: too many arguments to function call, expected 2, have 3../../mojo/shell/application_manager_apptest_target.cc:28:10: error: no matching member function for call to 'ConnectToService'../../ui/events/ozone/device/udev/device_manager_udev.cc:93:40: error: no member named 'WatchFileDescriptor' in 'base::MessageLoopForUI'
I submitted this CL on Friday and it is now breaking on Windows:https://codereview.chromium.org/986503002/Here is the build output:Is Windows using a GYP or GN build? I think it is GYP since GN is only recommended for Linux.The file that has a build error, leak_detector_impl.cc, is included in the GYP/GN build as a part of a module, leak_detector:
This module is a dependency of the leak detector unit tests module, which is defined as ChromeOS-only:Am I missing something here? Do modules get compiled and discarded even if nothing depends on them?Simon
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
it's a goal to have all targets that exist on each platform compile fine on all platforms.
--
I have also gotten strong feedback that having "ninja -C out/Debug" continue to work across all platforms was actually a *non-goal* in general, and that changing gypfiles solely for the purpose of preserving that feature on a specific platform (iOS in this case) was discouraged.
Huh, if anyone disagrees with this, please talk to me :-)(Or, Stuart, Colin: Let me know who pushed back, I'd like to talk to them.)Having a project that actually compiles seems like the lowest level on a project's hierarchy of needs.
On Tuesday, November 24, 2015, Nico Weber <tha...@chromium.org> wrote:Huh, if anyone disagrees with this, please talk to me :-)(Or, Stuart, Colin: Let me know who pushed back, I'd like to talk to them.)Having a project that actually compiles seems like the lowest level on a project's hierarchy of needs.Yeah, we broke this in the GN build accidentally and people were very confused.However, if iOS people are aaying this, I suspect the genesis of this feeling was that we didn't want to has iOS conditionals around absolutely everything because of the messy way that iOS integrates (at least historically).All main desktop builds should build everything properly. Whether I think we should do this for iOS will depend on what such a world looks like. Hopefully with the build cleanup and componentization work this will be reasonable.
On Tuesday, November 24, 2015, Nico Weber <tha...@chromium.org> wrote:Huh, if anyone disagrees with this, please talk to me :-)(Or, Stuart, Colin: Let me know who pushed back, I'd like to talk to them.)Having a project that actually compiles seems like the lowest level on a project's hierarchy of needs.Yeah, we broke this in the GN build accidentally and people were very confused.However, if iOS people are aaying this, I suspect the genesis of this feeling was that we didn't want to has iOS conditionals around absolutely everything because of the messy way that iOS integrates (at least historically).All main desktop builds should build everything properly. Whether I think we should do this for iOS will depend on what such a world looks like. Hopefully with the build cleanup and componentization work this will be reasonable.