I'd have to agree with the sentiments against C-style pre-processing. Anything that breaks linting or an IDE's static analysis would make development a pain.
Eli Perelman On Wed, Nov 25, 2015 at 11:55 AM, Sam Giles <[email protected]> wrote: > 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 <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-fxos >>>> >>>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >>> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-fxos >> >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
