Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File import support #109

Closed
wyozi opened this issue Dec 14, 2015 · 2 comments
Closed

File import support #109

wyozi opened this issue Dec 14, 2015 · 2 comments

Comments

@wyozi
Copy link
Contributor

wyozi commented Dec 14, 2015

I have already done some work on this: wyozi/glsl4idea@3790e4f

Some questions I've come up with:

  • Currently the syntax for imports is #pragma import "filename". Should that be modifiable by user?
  • I created a new preprocessor directive class for pragma directives (wyozi@3790e4f#diff-99fdab8cdb397e8e8a77b2b6903c0e58R26). It might be a good idea to create a completely different class for imports, although current approach would somewhat easily allow user to specify custom syntax to use for pragma imports.
  • Import files (stored in GLSLFile) are not cached at all currently. I'm not sure what would be the best way to cache them so that they still update every time imports are updated within code.
  • Import location is not used at all currently: imported file's types and identifiers are available globally in the file that imports them. This is in contrast with references that currently only resolve to nodes declared before the reference's source node.
@Darkyenus
Copy link
Owner

The import syntax is not standardized, so it should be definitely configurable, because everyone will implement it differently.

Those are issues that are holding #6 behind, implementing this functionality correctly is not trivial. I'd prefer resolving that first, it should solve or bring closer to solving this issue as well.

@wyozi
Copy link
Contributor Author

wyozi commented Dec 14, 2015

I guess it depends on whether #6 is solved via function repository or implicitly importing environment glsl files. From what I understand using environment glsl files would be trivial to add after file imports are implemented (excluding the fact that version/stage inferring still need to be implemented) so in that case it does not really matter whether this or #6 is solved first. Of course I'm biased because I'm a big fan of shader imports.

I do agree that adding support for built-in functions would be a higher priority though. I guess I could focus my efforts on trying to implement support for those using the environment glsl files, and then if it is still decided to go with the function repository approach I could still convert my code to be used for shader imports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants