I was surprised having worked in m-c that Gaia wasn't using the C pre-processor fwiw.
But I think the fact it will break syntax is a show stopper - unless we pre-process before linting - but the problem is deeper than that, I think the approachability of the code base will be affected by this. Not because the C pre-processor is obscure, I don't think it is at all, but because the syntax is just different to what you might expect. I'd also be worried about how easy it is to set up the toolchain for Windows developers. I don't see what the problem with the third party pre-processor proposed is, it at least covers what we already have in a better way and despite encasing the conditions in comments, is practically offering the same as the C pre-processor–without macros 🙌. Sam On Wed, Nov 25, 2015 at 5:31 PM, David Flanagan <dflana...@mozilla.com> wrote: > If there is a pre-processing system that is already familiar to the > majority of web developers, I'd buy this argument. But I don't think there > is. So most web developers who encounter preprocessing in FirefoxOS will > have to learn our system from scratch. If that is true, then I'd favor the > solution with 40+ years of use over something that someone just made up and > posted on github. And if `#ifdef FOO` scares away contributors then I > don't see how `<!-- @ifdef FOO -->` is any less scary! Its not like I'm > suggesting we use m4 here. > > If the argument is that we need a preprocessor that we can run in node > without invoking the shell, then maybe we can find a cpp implementation in > node. > > Maybe we want a syntax that uses comments so that the code remains valid > even before preprocessing so that linters and other tools don't get > confused. That seems like a reason that we need something other than cpp. > > Greg thinks that we need a preprocessor that can do template expansion and > looping. I find that surprising and a little scary, but I don't know what > the use case is. > > Anyway, my point is that the C preprocessor is venerable and well > understood by generations of programmers. IT seems to me that any > discussion of "what preprocessor should we use" should begin with the > question "can we just use cpp?" > > David > > > > On Wed, Nov 25, 2015 at 8:14 AM, Justin D'Arcangelo < > jdarcang...@mozilla.com> wrote: > >> We should use a preprocessor that is familiar to web/JS devs. We're >> trying to grow contributors, not scare them away. >> >> -Justin >> >> >> On Nov 25, 2015, at 11:08 AM, David Flanagan <dflana...@mozilla.com> >> wrote: >> >> Why can't we use the standard C preprocessor (with #if, #ifdef, #define, >> and even #include) for this instead of adopting a new technology? >> >> David >> >> P.S. When we do adopt a preprocessor solution, I'm interested to explore >> whether I can use it to include unit tests in the same file as the code >> being tested. >> >> On Tue, Nov 24, 2015 at 9:54 PM, Fred Lin <f...@mozilla.com> wrote: >> >>> Seems we have kind of common agreement to reuse the third-party >>> preprocess library[1]. >>> >>> Francisco has done some experiment port, and found the library has some >>> node dependency. >>> It also brings the request to have the node based build script. >>> >>> >>> 1. https://github.com/jsoverson/preprocess >>> <https://github.com/jsoverson/preprocess> >>> >>> >>> regards >>> -- >>> Fred >>> >>> On Wed, Nov 18, 2015 at 10:40 PM, Francisco Jordano < >>> fjord...@mozilla.com> wrote: >>> >>>> +1 to this, >>>> >>>> several reasons to do it: >>>> >>>> - It support multiple languages (javascript, html, css, c, etc) >>>> - You can combine as many options as you want. >>>> - The options have value, which could add a complete new set of cases, >>>> not just the binary one. >>>> >>>> Cheers, >>>> f >>>> >>>> On 18 November 2015 at 14:07, Fred Lin <f...@mozilla.com> wrote: >>>> >>>>> In Gaia currently we have preprocessor.js[1] that support some >>>>> syntax[2] to exclude/include HTML/JS/CSS in build time. >>>>> >>>>> With this tool, developer can exclude files, code sections from origin >>>>> HTML/JS/CSS files to shape the source to fit more kinds of devices. >>>>> >>>>> >>>>> >>>>> html code.... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <!--IFDEF_FIREFOX_SYNC >>>>> html code section >>>>> ENDIF_SAMPLE--> >>>>> >>>>> The consideration during review is we can't put html related comments >>>>> inside of <!-- -->, which make bad patten match and also make the editor >>>>> cry. >>>>> >>>>> As my experience about other code mangler/optimizer, some of them >>>>> support Ruby like start/end syntax, such as: >>>>> >>>>> <!-- @if NODE_ENV='production' --><script >>>>> src="some/production/lib/like/analytics.js"></script><!-- @endif --> >>>>> >>>>> Which wrap target code section with start comment and end comment, >>>>> therefore the origin source is still viewable in plain HTML. May we have >>>>> something similar so we won't left orphan comments in HTML file? >>>>> >>>>> >>>>> Another thought is since we can use npm modules now (Not 100% sure), >>>>> why we don't reuse existing preprocessor[3] and send PR to them to >>>>> leverage >>>>> efforts from outside talents? >>>>> >>>>> >>>>> 1. >>>>> https://github.com/mozilla-b2g/gaia/blob/master/build/preprocessor.js >>>>> 2. >>>>> https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/elements/root.html#L140 >>>>> 3. https://github.com/jsoverson/preprocess >>>>> >>>>> regards >>>>> -- >>>>> Fred >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> dev-fxos@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >>> >> _______________________________________________ >> dev-fxos mailing list >> dev-fxos@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-fxos >> >> > > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
