Why doesn't the C99 backend place the resulting C code in the same directory as the original spec?

[ivanperez-keera]

I find it a bit frustrating that I cannot compile a Copilot spec from wherever and I have to move the resulting files to where the original spec is. While I can modify the spec to specify a directory, I cannot modify the spec to mean "in the same directory where the spec is".

As a common user of sandboxes, my scenario is the following:

• Copilot is installed in ~/copilot, locally using sandboxes.
• Ogma is installed in ~/ogma, locally using sandboxes.
• I generate a cFS application.
• To compile the Copilot file that accompanies the generated application, I have to either install Copilot again, or create a sandbox in the cFS application directory pointing to ~/copilot/.cabal-sandbox, or do runhaskell from ~/copilot and move the resulting copilot{.c,.h,_types.h} to the cFS application directory.

I would have preferred to have the generated files be in the same directory as the spec, so that I could cd into ~/copilot and just runhaskell of the Copilot spec file, wherever it it.

[RyanGlScott]

I don't have a particularly strong opinion about what the default behavior should be, so I'm open to changing it.

[RyanGlScott]

Note that copilot-bluespec uses the same conventions for where to generate Bluespec files, so if we change the conventions in copilot-c99, then we should follow suit in copilot-bluespec.

[tkann-galois]

Based on the way Haskell is interpreted this might be a somewhat difficult thing to implement and almost any implementation would be somewhat inelegant. Namely Haskell doesn't have an easy call-site-determiner, so some workaround needs to be done. Some options that I've been able to find from logging packages are:

• use {-# LANGUAGE CPP #-} to access to the __FILE__ macro but this would need to be done in the compiling script, making it a bit clunky
• Template Haskell gives access to the qLocation monad that can be exported to the call site. This would similarly require {-# LANGUAGE TEMPLATEHASKELL #-} in all copilot compilations (so it may be possible to re-export it within copilot language) and would then require something like compile $(here) where the $(*) syntax is templated out at compile time

however, both of these options (as far as I can tell in testing) only work if the copilot spec is being ran like a script (i.e. $> runhaskell spec.hs instead of $> ghci spec.hs && ./spec). If the spec is being compiled there's another option

• using env-args to get the path of the 0th argument = the executable path; but this only works when it's being executed.

I'd wager there are ways to switch down one control path if haskell is compiled and down another if it's run without being compiled. But, in all cases there is added boilerplate code to add instead of just choosing a different option in the cSettings, unfortunately.