I'm working on a school project that consists of handling a list of contact in OCaml. The thing is that we have to make modules but I'm not really sure to have understand how that works. I have an agenda.ml, agenda.mli, contact.ml and contact.mli but when I wanna use agenda.ml it says that Contact is an unbound value when I call a Contact.function even if I already did #use "contact.ml".
Could someone explain me that whole thingy of module please?
If you are using the toplevel, you need to use #mod_use <filename> rather than #use <filename>: #use <filename> simply reads the contents of the filename inside the current scope, whereas #mod_use <filename> use the file to define a new module <Filename> in the current scope.
However, both #mod_use and #use are simple textual directive that cannot work with pair of ml and mli files. You will need at some point to read on OCaml build system. For simple school project, ocamlbuild might be a good idea: compiling a whole project might be as simple as ocamlbuild <main>.native.
Related
I'm writing a custom check for installed libraries in autoconf:
AC_DEFUN([AC_GHC_PKG_CHECK],[
...
GHC_PKG_RESULT=$($PYTHON autotools/check-ghc-version-range ....)
...
])
where my Python script that actually performs the check resides in the autotools/ sub-directory of the project.
However, this is not portable, for example make dist-check fails because then autoconf tools are called from a different directory. How can I reference the absolute path to my Python script so that it gets called properly no matter what the current directory is?
ac_top_srcdir or ac_abs_top_srcdir should work in this case:
AC_DEFUN([AC_GHC_PKG_CHECK],[
...
GHC_PKG_RESULT=$($PYTHON $ac_top_srcdir/autotools/check-ghc-version-range ....)
...
])
EDIT: I don't think this approach will work -- it seems that $ac_top_srcdir aren't evaluated until later (AC_OUTPUT?).
What I think might work in this instance is to do something similar to what the runtime C tests do: blast a configuration test to a temporary file (conftest.py instead of conftest.c in this case) and run it. Unfortunately, there's (yet) no builtin macros or for automake/autoconf other tools that directly assist with this task.
Fortunately it seems that a clever person has written at least a couple different ways to do this. The first one is GNU pyconfigure which seems to have facilities for writing Python test code as I described above. The second one is more of an ad hoc macro collection that he used for his project.
You can use $srcdir.
It's not necessarily an absolute path, but it's a path that points from the top of the build tree to the top of the source tree.
I am trying to implement a custom IPCore for the Zedboard. In my User_Logic I am including a component (My_Module) from the VHDL module (My_Module.vhd) which I wrote as part of the ISE project. But when I come to generate the bitstream for my design in PlanAhead it asks for the My_Module.ngc as if it is treating it as a blackbox. I though the NGC was only required when using CoreGen IPCores, but it seems it also wants it for any VHDL module included as I guess this is a 'black box'.
The issue is how do I create a NGC file from the VHDL for this module, which is part of an ISE project. As I can't find any function in ISE that allows you to just generate the netlist for one VHDL module. Or can I export this module out into a separate ISE project and then synthesise it to get the .ngc?
Many thanks
Sam
Are you sure you've typed the module name in exactly the same way both in your module .vhd file, and in the file using the module as a component?
Under normal circumstances, if your project includes the module as a .vhd file, it'll just be synthesized along with the rest of your sources - I did a quick test and renamed a component in one of my own projects, and got a complaint about a possibly missing .ngc file (this was in ISE, and not in PlanAhead though).
So the answer is to generate the NGC files by making the modules you want "the top module" you can then run the synthesis to generate the individual NGC. Then proceed as normal when adding IP to a PCore. So adding these NGC files to the netlist folder and modifying the BBD file and all that!
As a note for completion to get the module working you need to set the synthesis setting "Xilinx Specefic" -> and disable "add io buffers"
Are you including My_Module.vhd as a source file in your ISE Project? If you are, check to see that the ISE project doesn't have a yellow question mark next to the My_Module component. If it does, then it needs more information about that component. You should see a little icon with the letters VHD in it in your ISE Implementation Hierarchy View.
I've used simple makefiles for years, but only recently been assigned the task of learning the ins and outs of a large, complicated set of Autotools-generated makefiles which is used for a code base my employer has bought. In these, I'm running into variable declarations like the following:
QOBJECT_MOCSRCS = $(QOBJECT_HEADER:%.h=.gen/moc_%.cpp) \
$(QOBJECT_SRCS:%.cpp=.gen/moc_%.cpp)
QOBJECT_DEPS = $(QOBJECT_MOCSRCS:%.cpp=.deps/%.Po)
My best guess from context is that these set up lists of names of files to be provided by the build process, eg., QOBJECT_MOCSRCS should end up as a list of (a) .h files, (b) .cpp files, based on the % stem names of a set of intermediate .cpp files which will be generated during the build, in a temporary directory ./gen. This is used to store the moc_%.cpp files which are output as a result of a build of Qt files with Qt's moc tool...what is driving me crazy, is that I have been unable to find anything in any make documentation I've got (mostly the GNU make manual) that tells me what this style of declaration is called, so I can track it down and get a grip on the syntax. The contents of the $() look sort of like rules, and the nearest equivalents in the GNU make manual seem to be rules specifying target-specific variable values, but I have no idea whether this is anywhere near a correct reading. Can anyone point me to an appropriate reference for study?
This feature is called substitution references, http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html#Substitution-Refs
I try to use two external Fortran module which are in same name (in this case mod_param). So, when i try to compile my code, the compiler gives the following error,
mod_param.o: In function mod_param._':
mod_param.f90:(.text+0x0): multiple definition ofmod_param._'
mod_param.o:mod_param.F90:(.text+0x0): first defined here
is there any way to solve it without renaming the one of the module file and its name? I don't prefer the renaming because the external modules are maintained by someone else and i don't want to play with them. Is there any special use statement to do that?
No. It is necessary to change the function name in the source code in at least one of the modules.
Since the code is being maintained by someone else, consider automating the renaming: perhaps the project Makefile can run a sed script which changes the function names. So that the dependencies are clear, be sure to make the output of the sed script a new file name which is used to be compiled—the virgin module would have a filename which is not compiled or linked into the project.
Even if it were somehow possible to link them both in with the same name, how would you control which was called with the name?
According to F2003 standard module names are global entities and must be unique in a program, with some exteptions for intrinsic modules.
So, that would be a no (Besides, how would you tell them apart were they of the same name?)
There are struct definitions in the .h file that my library creates after I build it.. but I cannot find these in the corresponding .h.in. Can somebody tell me how all this works and where it gets the extra info from?
To be specific: I am building pth, the userspace threading library. It has pth_p.h.in, which doesn't contain the struct definition I am looking for, yet when I build the library, a pth_p.h appears and it has the definition I need.
In fact, I have searched every single file in the library before it is built and cannot find where it is generating the struct definition.
Pth uses GNU Autoconf, Automake, and Libtool. By running ./configure you'll be running a shell script which eventually runs m4 to detect the presence of a whole bunch of different system attributes and make changes to a number of files.
It looks like it boils down to ./configure generating Makefile from Makefile.in and then running something via make that triggers the shtool subcommand scpp:
pth_p.h: $(S)pth_p.h.in
$(SHTOOL) scpp -o pth_p.h -t $(S)pth_p.h.in -Dcpp -Cintern -M '==#==' $(HSRCS)
Obscure link, but here's an shtool-scpp manpage, which describes it as:
This command is an additional ANSI C
source file pre-processor for sharing
cpp(1) code segments, internal
variables and internal functions. The
intention for this comes from writing
libraries in ANSI C. Here a common
shared internal header file is usually
used for sharing information between
the library source files.
The operation is to parse special
constructs in files, generate a few
things out of these constructs and
insert them at position mark in tfile
by writing the output to ofile.
Additionally the files are never
touched or modified. Instead the
constructs are removed later by the
cpp(1) phase of the build process. The
only prerequisite is that every file
has a ``"#include ""ofile"""'' at the
top.
.h.in is probably processed within a configure (generated from configure.ac) script, look out for
AC_CONFIG_FILES([thatfile.h])
It replaces variables of the form #VAR# in the .in file with their values.
Edit: Just noticed if I'm right you should retag your question