885544 - Stop setting Firefox compatibility when using DEBUG=1 mode

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Alexandre Poirot [:ochameau]]

In bug 866702, we choosed to automagically enable gaia's Firefox compatiblity mode when you set DEBUG=1. This mode ends up being incompatible with b2g-desktop.
I tend to think that it ends up being more misleading than helpfull.
If we keep the current behavior, you will have to do:
  DEBUG=1 DESKTOP=0 make
in order to run on b2g-desktop.
I'd prefert to keep:
  DEBUG=1 make
and educate developers to do the following in order to run on firefox:
  DEBUG=1 DESKTOP=1 make

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Pull request 10515

Kevin, I know you prefer the current behavior, but when I see the issues it can create in bug 882760, I'd prefer modifying it :/

Comment 2

[Kevin Grandon :kgrandon]

If this is the case then I will be happy if we can make DESKTOP=1 make set the DEBUG=1 flag as well. Basically instead of DEBUG=1 make, developers could simply type: DESKTOP=1 make, and they would be ready to work in a browser.

My real preference would be to actually implement a new flag instead of DEBUG so developer workflow is not changed, but this change shouldn't be too bad.

Comment 3

[Kevin Grandon :kgrandon]

Comment on attachment 765627 [details]
Pull request 10515

I will be totally happy if migrate to only having to type DESKTOP=1 make, or create a `different` DEBUG flag for tools/b2g desktop.

Comment 4

[Julien Wajsberg [:julienw]]

I think we need to separate the technical things we do and the functional things we want.

We want :
* run unit tests (in the browser and in b2g desktop) => UNIT=1
* debug apps in the browser => DESKTOP=1
* simulator => SIMULATOR=1
* other stuff we could have later

We do :
* change settings and/or prefs => needed for tests, desktop, simulator (maybe not the same set for all of them)
* add httpd extension => needed for tests and desktop
* add helper extensions => needed for desktop and simulator

Therefore, we need to uncouple the functional things from the technical things. This is more like a matricial array of functionalities.

external env variable UNIT=1 would trigger internal DEBUG=1 (change settings/prefs), HTTPD=1 (install httpd extension)

external env variable DESKTOP=1 would trigger internal DEBUG=1 (change settings/prefs), HTTPD=1 (install httpd extension), HELPERS=1 (install helper extensions)

external env variable SIMULATOR=1 would trigger internal DEBUG=1 (change settings/prefs), HELPERS=1 (install helper extensions)

Incidentally, this would need different profile folders of course (because all of this install stuff in the profile) so we can build on the work done in Bug 864751 for this.

I may have missed something in what we need, but you get the point. The point is to _not_ change an existing environment for the sake of having another environment.