How to configure _oasis for OCaml to set 'Profile' flag - ocaml

I have an existing project in OCaml and one _oasis file. I don't know where to enable the profiling flag for ocamlbuild.
I looked up Oasis manual and the code, and found there was a variable profile available in setup.data. I assume this was what Oasis auto generated.
Where and what should I include in _oasis to set profile to true ?

You can activate the ocamlbuild_more_args feature.
On top of your _oasis file:
AlphaFeatures: ocamlbuild_more_args
Then, in your Package:
XOCamlbuildExtraArgs: your_ocamlbuild_option
I can't find any -profile option in ocamlbuild though, so I'm not sure of what this is about. Also, this option is still quite unstable.
A better way to handle that would be to modify your _tags file accordingly. It is generated by oasis but you can modify it.
EDIT:
setup.data informs you of environment variables. As for profile, it shows if the -p option will be passed to ocamlopt. You can pass it using the NativeOpt field.

You can enable the oasis profile flag by adding the --enable-profile argument to the ./configure flag. But so far, I have only noticed any effect when I enabled native code compilation (CompiledObject: native in _oasis). Even then, the profiling generation is only done for gprof.

I suggest you to use _tags file as it is the easiest way. Just add the following to your _tags:
<true> : profile
You run this command:
echo "<true> : profile" >> _tags
in the folder where your _tags file is located.
If you still want to use _oasis file, then you can use NativeOpt field, to add options that will be passed to native compiler, i.e., ocamlopt.

Related

Using Ocamlbuild plugins with Oasis

What is the proper way to integrate Ocamlbuild plugins like Ocamlbuild-protoc into a project managed by Oasis? I know how to manually edit myocamlbuild.ml to invoke the plugin, but that's not enough, because the proper tags have not been set. According to this particular plugin docs, it needs to be invoked with the following command, but I don't know how to do it in Oasis:
ocamlbuild -use-ocamlfind -plugin-tag "package(ocamlbuild_protoc)" target.native
Or is there maybe builtin support for Ocamlbuild plugins in Oasis that I missed?
Add to your _oasis file (outside any section) the line AlphaFeatures: ocamlbuild_more_args and XOCamlbuildExtraArgs: "-plugin-tag 'package(ocamlbuild_protoc)'".

Exporting cmake-gui options

I have a library with a bunch of different configuration options. We usually configure the build with cmake-gui and ticking a few checkboxes.
I want to automate this into a .sh script using just cmake.
e.g.
In GUI -> selects a bunch of different options
equivalent cmake command -> cmake -D CMAKE_XXX=X -D CMAKE_XXY=XXY [a bunch of options here] ..
How can I find the "equivalent" cmake command-line command to any arbitrary configuration I choose from the GUI?
The equivalent cmake command to cache a variable is explained here (-D option). Note that previous documentation was ambiguous, so take care of always checking the latest one.
Basically:
-D<var>:<type>=<value>
You have to specify also the type to have the variable cached in the same way as through your cmake-gui procedure. Note that variable definition is necessary only the first time: if not specified anymore, the cached value will be used.
cmake-gui generates CMakeVars.txt and CMakeCache.txt files in the build directory once you click "Configure" button. They cache all variables you configured through the GUI.
Had the same question ... and as you asked I looking up some of the options in the menu and found it. Menu Tools -> Show My Changes
Bringing up an Dialog with an edit field with content for command line options or cache file options.
yeah
p.s. I used cmake 3.11.1
just read file named like CMakeCache.txt (iirc) in the root of build directory and see variable names there
You can write a file containing all variables you want to set with set(<var_name> <value>) and pass this file to the CMake call via -C:
cmake -C <fileWithInitialValues> <pathToSrcDir>
Documentation:
https://cmake.org/cmake/help/v3.3/manual/cmake.1.html
This should would similar with cmake-gui and ccmake, but it is not a pure solution with the graphic interface.

Vim YouCompleteMe configuration

i just installed YouCompleteMe for Vim through vundle. It works, but it shows only the words contained in the current file. I want to use it to develop c++ programs, how can i configure it to show autocompletion from c++ headers file in /usr/include for example? Thanks a lot.
You need to navigate to ~/.vim/bundles/YouCompleteMe and run the installation script with --clang-completer, so do ./install.sh --clang-completer. After it finishes you should have support for C like languages.
You may also need to place let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py' in your ~/.vimrc.
I have installed with pathogen. I tried the above instructions with ./install.sh --clang-complete. After this, it did not work, and I indeed had to add the path. But it was different than in another reply here, namely
let g:ycm_global_ycm_extra_conf = '.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py'
so there is an extra "third_party/ycmd" in the path.
While the suggestions here might work in the beginning, I am not sure it's the proper way to go. According to YCM developer, whenever you start a project, you need a new .ycm_extra_conf.py file
From https://valloric.github.io/YouCompleteMe/#ubuntu-linux-x64-super-quick-installation
YCM looks for a .ycm_extra_conf.py file in the directory of the opened file or in any directory above it in the hierarchy (recursively); when the file is found, it is loaded (only once!) as a Python module. YCM calls a FlagsForFile method in that module which should provide it with the information necessary to compile the current file. You can also provide a path to a global .ycm_extra_conf.py file, which will be used as a fallback. To prevent the execution of malicious code from a file you didn't write YCM will ask you once per .ycm_extra_conf.py if it is safe to load. This can be disabled and you can white-/blacklist files. See the Options section for more details.
While you might only need to modify the compile flags from the vanilla .ycm_extra_conf.py, I feel it is advisable to create a new file for every project you start.
Everything that the folks here have said is correct. I just want to add that as of 2017, the "install.sh" script is deprecated. Now, you have to use the install.py script instead by typing
./install.py --clang-completer
Also, in your .vimrc file, instead of ".vim/bundle/blahblahblah", you'll need to add a "~/" in front of the address by adding:
let g:ycm_global_ycm_extra_conf = "~/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py"
to your .vimrc file, to give it an absolute path from the Home directory so that Vim can find the ".ycm_extra_conf.py" file. Otherwise, you might experience some funny behavior.
I just wanted to add if you don't want to manually define a config file there is this neat little repository that will auto generate it. https://github.com/rdnetto/YCM-Generator

Ocamlbuild override the default options

My installation of OCaml does not recognize #!, therefore camlp4o cannot be ran standalone. It must be invoked as "ocamlrun camlp4o".
I try to add a flag in the plugin. But the new flag is simply added to the existing flag.
The result is that ocamlbuild will invoke the compiler with
"-pp camlp4o ocamlrun camlp4o".
A working workaround is to introduce a new tag 'my_camlp4o'. However, the documentation of ocamlbuild did mention the capability of 'overriding' defaults. It seems ocamlc, ocamlopt can be overridden. But can we override camlp4o? Can it be done in plugins?
There is support for changing defaults in Ocamlbuild, through the -ocamlc <command>, -ocamldep <command> etc. command-line options. Unfortunately, camlp4 is currently not part of the set of customizable commands. Could you please use the issue tracker to request this feature?
(In the meantime I recommend a workaround, eg. you replace the ocamlrun executable in your PATH by an executable script that does the right thing.)
Edit
Another workaround is to do all your compilation through ocamlfind, which has support for overriding the camlp4 command (see the documentation), and can be used as a basis for all ocamlbuild command with the -use-ocamlfind option. Unfortunately, ocamlfind itself only supports preprocessing at compile-time (when invoking the actual compiler), not stand-alone source-to-source processing, so that may not cover your own use case.

Expand macro inside doxygen comment for printing out software version

I have some C++ code base, documented with doxygen, and build with GNU make.
Version information is centralized in makefile, where I have something like:
VERSION=1.2.3.4
In my makefile, the CFLAGS add the following define:
CFLAGS += -DAPP_VERSION=$(VERSION)
This enables me to get the version in code, like this:
#define STR_EXPAND(tok) #tok
#define STR(tok) STR_EXPAND(tok)
int main()
{
cout << "software version is << STR(APP_VERSION) << endl;
}
Now, what I would like is to have this in the doxygen-produced html files:
Current version of software is 1.2.3.4
I managed to export the makefile variable into the doxygen configuration file with:
(edit: doxygen is called from makefile, through a 'make-doc' target)
PREDEFINED = APP_VERSION=$(VERSION)
But then, if I try in the doxygen \mainpage command something like this, it fails, because (of course), macro names don't get expanded in comments...
/**
\mainpage this is the doc
Current version is $(APP_VERSION) -- or -- ... is APP_VERSION
*/
Questions
Do you know of a way to "expand" that macro in the doxygen comments ? This could be done by some sed processing on the file holding the comment in the makefile, but maybe this can be solved directly with doxygen ?
How do other projects handle versioning (besides automatic versioning tool that VCS provide, I mean), in a way that the version id is uniquely defined in a file, so it can be fetched both by software build system and documentation build system.
Related: How to display a defined value
Macros in comments are not generally expanded (see, for example, this answer). This is not unique to doxygen and I can 't think of a way to do this using the PREDEFINED configuration option.
As you state in the question, you can use sed, see the third bullet point in this answer. For example, using the following
INPUT_FILTER = "sed -e 's/VERSION/1.0/'"
will replace all instances of VERSION with 1.0 in all your source files (you can specify which files to process with INPUT_FILTER, rather than processing all source files). You might not want VERSION to be expanded everywhere, so perhaps it is best to use something like $(VERSION) and sed this token. Also, you will need a way of getting your version number from your makefile and into your doxygen configuration file. This can be done with another sed.
To address your last bullet point, doxygen has the FILE_VERSION_FILTER configuration option for determining the version number of each file. Using this will print some version information (whatever is printed to standard out from the command specified in FILE_VERSION_FILTER) at the top of each file page. In the documentation there are examples of getting the version number using a number of different version control systems. Also, here is a page describing how to use git and doxygen to extract version information.
The only drawback with this configuration option is that I don't know how to specify where the file version information should appear in the final documentation. I presume you can use a layout file: I presume you can change the layout of pages, but I have never done this and don't know how easy it would be to use this to include version information on the mainpage.
You need to use the "export" functionality of make ie a very simple make file with
project_name=FooBar
export project_name
all:
doxygen Doxyfile
Will allow you to use the following comments in C++
/*! \mainpage Project $(project_name) Lorem ipsum dolor
I can see this becoming a PITA with a large set of exports but it's a fairly simple way to do it. Alternatively you could run doxygen from a separate BASH script with all the exports in it to avoid polluting your Makefile too much.
the commands manual suggests that $(VARIABLE) expands environment variables. So maybe you can put your version in an environment variable?