Is it possible to customize the extension that haskell files can have?
That is, to tell GHC that a file with extension .yy.xxx should be accepted as a valid haskell file, and that a file with extension .yy.lxx should be accepted as literate haskell?
GHC has a -x option to override the meaning of file suffixes, see the user guide:
-x ⟨suffix⟩
Causes all files following this option on the command line to be processed as if they had the suffix ⟨suffix⟩. For example, to compile a Haskell module in the file M.my-hs, use ghc -c -x hs M.my-hs.
I've used this to compile .md files as .lhs (instead of storing the files directly as .lhs, which may prevent other tooling from telling the format to render from).
Related
Like
make,
scons has a large number of predefined variables and rules. (Try scons | wc on an SConstruct containing env = Environment(); print(env.Dump()) to see how extended the set is.)
But suppose we aren't after the wizardry of presets but rather want to do something a lot more primitive—simulating launching a few instructions from the (bash, etc) command line?
Also suppose we're quite happy with the default Decider('MD5'). What is the translation of the one-souce-one-target:
out/turquoise.xyz: out/chartreuse.xyz
chartreuse_to_turquoise $< $#
of the two-source-one-target:
out/purple.xyz: out/lilac.xyz out/salmon.xyz
gen_purple $< $#
and of:
run_this:
python prog.py
which we would run on-demand by typing make run_this?
What does the SConstruct for these elementary constructs look like?
All the answers you're looking for are in the users guide (and manpage)
Firstly, assuming you don't want to scan the input files to add included files specified in the input files, you can use Commmand()
(See info here: https://scons.org/doc/production/HTML/scons-user.html#chap-builders-commands)
Then you'll want an alias to specify an a non file command line target
(See here:https://scons.org/doc/production/HTML/scons-user.html#chap-alias)
Putting those two together yields
env=Environment()
# one source, one target
env.Command('out/turquoise.xyz', 'out/chartreuse.xyz', 'chartreuse_to_turquoise $SOURCE $TARGET')
# Two source, one target
env.Command('out/purple.xyz',['out/lilac.xyz','out/salmon.xyz'], 'gen_purple $SOURCES $TARGET')
# And your .phony make target which is actually not great for reproducibility and determining when it should be rerun, because you do not specify any sources or targets
env.Alias('run_this','python prog.py')
Note: SCons doesn't NOT propagate your shell environment variables. So if you depend on (for example) a non system path in your PATH, you'll need to explicitly specify that in env['ENV']['PATH'] for example. For more details take a read through the users guide, manpage and FAQ.
https://scons.org/doc/production/HTML/scons-user.html
https://scons.org/doc/production/HTML/scons-man.html
https://scons.org/faq.html
And you can reach the community directly via our discord server, IRC channel, or users mailing list
I found both ncvlog and Verdi can read the design through *.f which includes *.v files and +incdir commands. It's easy to get an example and modify it fit the new project.
However, is there have any specific description about .f file?
Commonly referred to as "dot-f" files, files that end with an extension of .f contain command-line arguments for the simulator. The .f extension is actually just a convention and not required by the tools. The the file is passed in with a -f or -F option.
Any command-line argument that the tool accepts can be placed within a file that is passed with the -f option.
Here is an excerpt from an old ncvlog manual I found online:
-File arguments_filename
Use the command-line arguments contained in the specified arguments file.
You can store frequently used or lengthy command lines by putting command-line arguments
(command options and top-level design unit names) in a text file. When you invoke the
elaborator with the -file option, the arguments in the arguments file are incorporated with
your command as if they had been entered on the command line.
The arguments file can contain command options, including other -file options, and
top-level design unit names. The individual arguments within the arguments file must be
separated by white space or comments.
As an example, the following two scenarios are equivalent:
Specify command-line arguments directly
$> ncvlog +incdir+foo mod1.v mod2.v mod3.v
Specify command-line arguments in a .f file
args.f:
+incdir+foo
mod1.v
mod2.v
mod3.v
$> ncvlog -f args.f
it's just some arguments, you can put file list, include directory, macro define, and other option here
I'm writing a program where the command line usage should be something like:
mkblueprint FILE FILE FILE -o <output name> -s <string> -r <number> -p pOPT1 pOPT2 pOPT3
I'm currently using CmdLib and I can't figure out a way to handle this; a flag is required for each input(so I can't just have FILEs sitting alone) and there doesn't appear to be a way to pass multiple arguments to a flag, as with -p. These are extremely common in command line programs so I figure I'm just misunderstanding the documentation, but it's not mentioned in any command line library I look at for Haskell.
After some more work with CmdLib I was able to handle the bare FILE input via the Extra tag and then checking that each string is a valid file, which seems to be the standard way to handle it despite the name. -p pOPT1 pOPT2 pOPT3 is apparently not allowed under the POSIX standard, which is why I'm not finding libraries that will do it.
You might consider the GetOpt bindings that come with base. They're not as sexy as some of the more modern alternatives, but they support bare arguments and final options well.
I am working in MinGW environment (downloaded with their installer on 12/12/2011). I am attempting to compile a resource (.rc) file using Windres. The specific command I use is
Windres -O coff About1.rc -o About1.res
Windres generates at least 100 lines of warning messages reading: "warning: null characters ignored". Following this Windres emits: "Abouty1.rc:1:syntax error".
As a matter of fact, there are no null characters in the About1.rc file. In addtition, the first line of the file is an include statement: #include "dlgresource.h". I played around and eliminated this statement and it turns out that it doesn't matter what I put there, I get the same flurry of messages and the syntax error notification.
To make things more confusing, this same .rc file compiles without any problem using MSFT's rc.exe. The resulting .res file links smoothly with the program .obj file and runs perfectly.
I have no idea what is going on. Any ideas?
Thanks,
Mark Allyn
Your .rc file is probably encoded as UTF-16.
That's what's required in general by Microsoft's [rc.exe], in order to be able to deal with international characters, but GNU [windres.exe] can only deal with ANSI encoding.
One workaround is to convert the file to ANSI on the spot (possibly losing e.g. Russian or Greek characters):
> chcp 1252
Active code page: 1252
> type my.rc | windres --output-format=COFF -o my.res
> _
You probably used VS or a similar tool to generate the file. There are some parts of the character encodings that you cannot see resulting in null characters and etc.
Generate a new .res file with the same content, don't copy/paste the content, type it in yourself.
Try:
windres About1.rc -o About1.o
and then just use the resulting .o file instead of the originally intended .res file.
I've had the same troubles than you today. I know it has passed a lot of time from your question, but I'm writting this on the hope that it can be useful for someone.
First, I obtained an object file .o compiled using Cygwin, writting:
windres -o resource.o resource.rc
By doing that, you dont need to use the .res file, but the .o one, and you can then link this object with all the others, when you compile yout program, using GNU resources:
g++ Header_files CPP_files flags ... -o program.exe recource.o -lm
For instance.
I am trying to create a target in my Makefile to automatically create a tags file using ctags.
I have a list of source files (.cpp files) but I don't have a list of all the header files (I use g++ -MM to create the list of header dependencies).
I would have assumed that ctags would follow any #include directives in the .cpp files when generating the tags, but it seems my assumption is wrong.
If I create a simple tags file like this:
ctags --fields=+iaS --extra=+q myClass.cpp
and then go into vim and type in the name of an object followed by a '.' I get the error "Pattern not found".
However, if I compile the tags file like this:
ctags --fields=+iaS --extra=+q myClass.cpp myClass.h
and do the same thing in vim I get a lovely auto-completed list of member variables/functions.
The first line in my 'myClass.cpp' file is
#include "myClass.h"
So why doesn't ctags use that to parse the header file too?
nope. unfortunately/fortunately.
There wouldn't be too many problems following your own includes. The problem starts with
conditional compilation
external (system) libraries.
Fortunately, the problem for your own libraries is easily solved by doing something like
ctags *.h *.cpp
ctags -R src/
You could hack something together with cpp and then ctags. It would not work conveniently. A half-interesting approach would be to patch ctags to follow the #line pragma's in cpp's output and hence relate all tags to their respective sources.
However, that approach would not work as you'd expect for any preprocessor symbols/defines (macros have been expanded, so you wouldn't be able to find a macro by ctags).
The usual way to resolve this, is to generate a 'standard' tags file for your external libraries, and
:se tags+=/home/me/libs/tags.stdc++
:se tags+=/home/me/libs/tags.libsox
etc. Several libraries have tutorials on how to make a useful tags file for use with their libraries (or prebuilt tags files assuming a certain folder layout)