Explanations on the Config datatype

[meditans]

My question is about the Types.Config data type, and the uses the code makes of exts, headers and includeDirs. This questions is not directly aimed at modifying or improving the code, I ask mainly to understand better how this works.

exts would be the extensions to activate in the parsing of the file. In the case in which the cabal file is read, is this option still useful? How?

Similarly, could you do an example in which headers and includeDirs are useful?

[rubik]

As of now, exts is only used when a Cabal file is read. It contains the extension names that are not in the code, that is, those that are activated in some other way (e.g. from a Cabal file). We could also add a -X command line option to add custom extensions from the command line, and they would end up in exts. The extensions that are specified in the file are activated automatically by the GHC parser, so there is no need to keep track of them.

You can check that headers and includeDirs are directly passed to the preprocessor at Parser.hs#L51.

The former contains the paths of additional header files that have to be included before performing the preprocessing, while the latter contains the paths of additional directories which contain additional header files. You'd use headers if you want to include a file which contains macros and definitions referenced in your code, and includeDirs to specify where to find certain headers you've used in the code. As you can see at Preprocess.hs#L48, those two config values directly map to the preprocessor's (e.g. gcc) -include and -I options.

As you can see at Main.hs#L30, the --cabal-macros is nothing but a synonym for headers.

Thanks for creating this issue. It made it possible to see where we can improve the command line options. We can now

• make it possible to specify more that one -I, --include-dir option (just as GCC does);
• add an --include-header option that can be specified multiple times (but leaving --cabal-macros because I still find it clearer);
• add a --define option, because currently there's no way to specify those;
• add an -X, --extension option that an be specified more than once in order to load additional extensions.

In order to do that we'll have to ditch Docopt, because the last time I checked it does not support options that can be specified more than once. There's a list here (I'm not sure if it's up-to-date) with various alternatives for option parsing.

[meditans]

Thanks, this makes things clearer. Can I ask why the cabal file is not searched/included automatically? It seems to me that the most common use case for argon is the parsing of an entire project.

Could you make an actual example of an use case in which new headers files are included via headers and includeDirs? It never happened to me and I'd like to get a better picture.

Regarding the command line options, it seems to me that the best solution for this use case is Gabriel's optparse-generic (besides, you talked about it here, come say hi on the irc channel sometimes xD).

[rubik]

The Cabal file could definitely be searched automatically, I just haven't done it yet. I've opened #30 about that.

If your preprocessing is somewhat advanced and/or complicated it makes sense to modularize it with headers. Personally, I'd steer clear from that, as I think preprocessing makes sense for very simple tasks, without introducing unneeded complexity.

In some cases preprocessing is an absolute necessity. For example, Argon makes use of the GHC API, and sometimes of its internals. Since those can (and do) change with time, there is no way other than CPP to support multiple versions. See, for instance, SYB/Utils.hs.

As I said, I wouldn't like to make my CPP much complicated, so apart from cabal_macros.h I don't have any other examples to make. Since Argon strives to support every file that can be compiled by GHC, it supports this feature even though it's rarely used.

optparse-generic is awesome, but it seems to me that right now positional and optional arguments are mutually exclusive. I'll see what can be done about it.

I don't use IRC that much, but I'll make sure to drop by sometimes 😄

[rubik]

Can I close this issue? Or if you have other questions I'm happy to answer them.

[meditans]

Sure, this issue can be closed. I'll probably ask a few more questions in another one though ;)

Thanks!