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

Extended preprocessors support #6232

Open
boris-stepanov opened this issue Sep 10, 2019 · 0 comments
Open

Extended preprocessors support #6232

boris-stepanov opened this issue Sep 10, 2019 · 0 comments
Labels
Cabal: hooks re: preprocessors Concerning preprocessors such as alex and happy type: enhancement

Comments

@boris-stepanov
Copy link

boris-stepanov commented Sep 10, 2019

Hey, Cabal team.

Some time ago, I had to integrate Apache Thrift in one of my projects. But, I faced issues with HookedPreprocessors.

Let's say, that we have a preprocessor that can translate files with the .foo extension. If you declare some module in your exposed-modules (f.e. Test.Module), then Cabal will look for the file named Test.Module.foo and run the preprocessor for it. It is one-to-one correspondence.

Now, we have Apache Thrift. The preprocessor can parse Thrift DSL and generate protocols and RPC servers/clients. But, it will translate single Module.thrift file in many others: Module_Types.hs, Module_Consts.hs, RPCPoint_Iface.hs, RPCPoint_Client.hs. The first two files correspond to the source file, while the rest correspond to a single RPCPoint service inside the Module.thrift. There can be other interface/client files, if you declare more services in the Module.thrift.

So, here is a problem: Cabal finds Test.Module in exposed-modules sections, finds Test/Module.thrift among source files and thinks that's it, but after the preprocessing stage, there is no Module.hs among the build files. On the other hand, if you declare Module_Types/Module_Consts and others in your exposed-modules section, that Cabal will ignore Module.thrift source file.

What I did in my project:

  1. I've placed the single pattern thrift/*.thrift in the extra-source-files field.
  2. I've written custom Setup.hs file with overloaded buildHook/testHook. Before running the default hook, they will call the thrift preprocessor for every file matching the pattern in extraSrcFiles with the destination buildDir.

This approach works, but I don't like it:

  1. Files specific for the build are listed in a global parameter.
  2. Part of preprocessing stage is placed in the buildHook. Also, I have duplicated code in the testHook (and I would have it in the benchHook, if I needed to).
  3. There are other preprocessors with similar problems.

I suggest to remove pattern matching on preprocessor stage at all. I think, time savings in case of dropping unnecessary files doesn't make a difference.

P.S. Here is a link on my Setup.hs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cabal: hooks re: preprocessors Concerning preprocessors such as alex and happy type: enhancement
Projects
None yet
Development

No branches or pull requests

4 participants