Any plans to implement @include?

[alekop]

Hi,

It would be nice to be able to pull in dependencies into a file before processing it. I just looked at the code, so I'm not sure how feasible this is.

Thanks!

[smartt]

I haven't touched that code in awhile, but a basic include shouldn't be too hard, depending on how it finds files. Do you have any ideas on how the format should look? I'd probably lean toward a relative import solution that supports unix-style paths. So:

@import foo.js
@import foo/bar.js
@import ../bar.js
@import ../bar/foo.js

..that sort of thing. We'd basically be handing the path over to a Python open() after resolving the relativeness.

[smartt]

Doing a basic @include wasn't too bad. Check out the diff above and see what you think.

It's a multi-pass include, so you can use jsmacro macros in the included files as well. I only added one test file though (although it does a couple different tests within it.)

Cheers!

[alekop]

Hey Erik,

Thanks for the quick turnaround!

The syntax seems perfectly reasonable. I was a bit surprised that the files are not wrapped in quotes, but this would only be an issue if the filenames contain spaces, which is unlikely.

So, it works in simple cases, but I ran into several issues with more complicated scenarios:

1. #include directives don't work if there are no other preprocessor directives in the same file. Example:

a.js:
//#include b.js
function a() {
}

b.js:
function b() {
}

./jsmacro.py -f a.js

//#include b.js
funciton a() {
}

But if a.js contains, say an #ifdef, then it works.

1. Using an #ifdef in a file with an #include messes up the #ifdef substitution. It looks like the substitution is working on the original file text, before the #includes were processed.
2. Conditional #includes don't work. #includes are not parsed if nested inside an #ifdef block. Other nested directives seem to work.

#2 is the only showstopper here. Otherwise it's a pretty useful little tool.

Thanks again.

[smartt]

Sounds like I need to write some more tests! :-)

I find that first "1." confusing because I'm pretty sure I tested that. I'll need to try replicated it. One thing that is a little strange with the current implementation is that it requires an #end, which is goofy. (I opened ticket #11 to fix this.)

Quotes (and spaces-in-filenames) didn't even cross my mind. Seems reasonable to (optionally) allow them. I opened a new ticket (#9) to track that feature.

Supporting conditional includes is awesome. I opened ticket #10 for that.

[alekop]

Thanks!
At this rate, you'll end up writing a full-blown C preprocessor. ;)

Speaking of which, I just thought of another useful feature... user-defined
macros!

//#ifdef DEBUG
//#define LOG(msg)
console.log(msg);
//#end // not sure if this necessary
//#else
//#define LOG
//#endif

function fn() {
// invoke user macro. the //# syntax would make it easier for the
// preprocessor to find macros in the code
//#LOG('In fn()...')
...
}

I have a feeling this one is going to be tricky. Especially the handling of
mutiline macros, and macro parameters.

On Wed, Sep 12, 2012 at 2:29 PM, smartt [email protected] wrote:

Sounds like I need to write some more tests! :-)

I find that first "1." confusing because I'm pretty sure I tested that.
I'll need to try replicated it. One thing that is a little strange with the
current implementation is that it requires an #end, which is goofy. (I
opened ticket #11 #11 to fix
this.)

Quotes (and spaces-in-filenames) didn't even cross my mind. Seems
reasonable to (optionally) allow them. I opened a new ticket (#9#9)
to track that feature.

Supporting conditional includes is awesome. I opened ticket #10https://github.com/smartt/jsmacro/issues/10for that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-8510723.