For me the main reason is to have the definitions in the same language that you are working with, whenever is html, css, or js, and if we would have C, definitely use C syntax.
We will have people that are familiar with the language, and also, we won't break our tools for linting, etc. Cheers, F. On 25 November 2015 at 16:08, 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

