Need your help:
I want to use Eclipse CDT and QT without creating a "Qt gui project". Is it possible? How to include QT libraries to my C++ project, and how to call qmake/make to compile the program? This Similar question didn't help me(
I want to use 'C++ project' instead of 'QT Gui project' because there is an issue with external libraries indexing in the QT project (this problem)
Thank you a lot!
Nikolai.
We've done something similar using Qt with a vendor customized version of Eclipse (Momentics) and CDT. To get it to work, we ended up creating a generic makefile project in Eclipse with our own, hand generated Makefile.
The hand generated Makefile basically contained enough information to invoke QMake on the appropriate .pro file ("qt.pro") and then invoke the resulting Makefile ("qtmake.mk").
all: qtmake.mk
$(MAKE) -f qtmake.mk
qtmake.mk: qt.pro
qmake -r -o qtmake.mk qt.pro
clean: qtmake.mk
$(MAKE) -f qtmake.mk clean
install: qtmake.mk
$(MAKE) -f qtmake.mk install
Doing this is quite bothering, I suggest you don't do it. I've tried it only on small projects.
As far as I know you'll have to write a correct Makefile yourself (or setup CDT to create it) by including all the include paths you need for Qt headers. Then you'll have to link to all the Qt libraries your project is using.
If you make use of the Qt meta-object system you'll have to run the moc before compiling and linking. The moc generates C++ sources that you'll have to link to the other sources. If you're using GNU make, and I guess you are, it seems to be possible to automate the moc writing the correct instructions in the Makefile CDT will create. For detailed information read this: http://doc.qt.io/qt-5/moc.html#writing-make-rules-for-invoking.
By the way, isn't it possible for you to use Qt Creator?
This is very easy making use of Netbeans, since qt is integrated in the c++ projects.
But if you use Eclipse, as is my case, you could follow these two steps (for linux users):
Include the directories with the Qt headers, for example /usr/include/qt4/Qt.
Generate the moc files from the headers that contain Qt macros, such as Q_OBJECT. This can be done using the following command in the project directory before the build process:
find . -name ".h" | sed 's/(.)(/)(.*)(.h)/moc-qt4 -D & -o \1\2moc_\3.cpp/' | sh
where you have to define the you want. Just run it once, or use the following command before from the project directory:
find . -name "moc_*.cpp" -exec -rm -f {} \;
Build your project.
By the way, have you tried the qt plugging?
J.
Here is an improved variant of the jwernerny's makefile:
first: all
all clean distclean install uninstall: qtmake.mk
$(MAKE) -f qtmake.mk $#
qtmake.mk: *.pro
qmake -r -o qtmake.mk $<
.PHONY: first all clean distclean install uninstall
It should not to be edited when will be copied to another project, and actually the same rules was merged into one.
Related
I understand what I believe is the essence of the official utilties doc https://coq.inria.fr/refman/practical-tools/utilities.html#building-a-coq-project:
one creates a _CoqProject with arguments to coqc and the file names to compile (hopefully in an order that takes into account dependencies)
then one make an automatic CoqMakefile with coq_makefile -f _CoqProject -o CoqMakefile
Then you use their recommended Makefile to run the automatically generated make file.
But then if we need other dependencies, it doesn't say how to install them (or uninstall) them. What is the standard way to do that?
My guess is that one likely adds a target to your Makefile at the end of it and do some sort of opam install?
e.g.
# KNOWNTARGETS will not be passed along to CoqMakefile
KNOWNTARGETS := CoqMakefile
# KNOWNFILES will not get implicit targets from the final rule, and so
# depending on them won't invoke the submake. TODO: Not sure what this means
# Warning: These files get declared as PHONY, so any targets depending
# on them always get rebuilt -- or better said, any rules which those names will have their cmds be re-ran (which is
# usually rebuilding functions since that is what make files are for)
KNOWNFILES := Makefile _CoqProject
# Runs invoke-coqmakefile rule if you do run make by itself. Sets the default goal to be used if no targets were specified on the command line.
.DEFAULT_GOAL := invoke-coqmakefile
# Depends on two files to run this, itself and our _CoqProject
CoqMakefile: Makefile _CoqProject
$(COQBIN)coq_makefile -f _CoqProject -o CoqMakefile
# Note make knows what is the make file in this case thanks to -f CoqMakefile
invoke-coqmakefile: CoqMakefile install_external_dependencies
$(MAKE) --no-print-directory -f CoqMakefile $(filter-out $(KNOWNTARGETS),$(MAKECMDGOALS))
#
.PHONY: invoke-coqmakefile $(KNOWNFILES)
####################################################################
## Your targets here ##
####################################################################
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
# I know this is not a good coq dependency example but just to make it concrete wrote some opam command
install_external_dependencies:
opam install coq-serapi
I think I wrote the install_external_dependencies in the right place but I'm not sure. Is that correct? Anyone has a real example?
For all the code see: https://github.com/brando90/ultimate-utils/tree/master/tutorials_for_myself/my_makefile_playground/beginner_coq_project_with_makefiles/debug_proj
related: question on official tutorial for building coq projects https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
Btw,
I don't understand the last like in the makefile yet.
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
i.e.
%true in the make file template coq gave us.
% in the name of the rule.
What does that line do?
Update
I'm seeking an end-to-end small demo of how to install all dependencies with whatever the recommended approach when using _CoqProject and coq_makefile as shown in the utilities doc https://coq.inria.fr/refman/practical-tools/utilities.html. The ideal answer would contain a single script to install and compile everything in one go -- say in a install_project_name.sh. Including opam switches etc.
Related:
How does one install a new version of Coq when it cannot find the repositories in a new Mac M1 machine?
Installing packages for Coq using OPAM
https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
The simplest setup is to install external dependencies manually with opam.
opam install packages-needed-by-my-project
Then they will be immediately available to build your own project.
The next level of organization is to package up your project. Refer to the following Coq community resources:
Coq community templates
Recommended Project Structure
The main thing immediately relevant to your question is to have a *.opam file at the root of your project which lists its dependencies (possibly with version requirements). Then you can install them using opam install . --deps-only.
The Makefile part of your question is about a bit of overengineering for passing options seamlessly to CoqMakefile. I'm not sure how it works off-hand, but it's not important anyway, especially because Dune is superseding make as the recommended build system for Coq project.
I have created a Yocto autotools project in Eclipse (based on a Hello World project).
I wanted to separate my code into a number of libs and then link them in a form of static libs (.a) to my project.
Now I have one app and a number of static libs. However, no matter what I try I can't get my code to compile. Each separate lib compiles and produces a .a file, but my app doesn't.
After searching the web I have a possible solution - add a direct link to my static libs:
MyApp_CPPFLAGS="-I$LOCATION"
MyApp_LDADD="/home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a"
This is my Makefile.am file, where libEncoding2.a exist in that path.
The error I get is:
make[2]: *** No rule to make target `"/home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a"', needed by `MyApp'. Stop.
I already built the lib so I am not sure why a make try is even needed.
Any help will be appreciated.
Because you use static library in your recipes, you can make a soft link to the library in your project source folder, i.e., hello-world-0.1, using following command to link to your static library
ln -s /home/xxx/workspace/MyApp/Encoding2/Debug/libEncoding2.a
and then edit your bb file, hello-world_0.1.bb, adding the source path to your URL
SRC_URI = " \
file://libEncoding2.a \
file://hello-world.c \
"
and in the do_compile block, using follow command to compile your project
do_compile() {
${CC} hello-world.c libEncoding.a -o hello-world
}
do_install() {
install -d ${D}${bindir}/Hello
install -m 0755 enet ${D}${bindir}/Hello
}
After you bitbake your project
bitbake hello-world
and run mkefidisk.sh, you can find the hello-world in /usr/bin/Hello/hello-world. Hope this hint can help you.
BTW, I am not familiar with autotools, I just use make to bitbake the recipes. And your static library should also be created in Yocto not in Eclipse I think. So I think your path for the static library maybe not correct, it should locate in ~/yocto/build/tmp/... or some where like this. In my case, it was located in ln -s ~/yocto/build/tmp/sysroots/intel-corei7-64/usr/lib/libEncoding.a depends on your target environment.
Depending on whether you're using libtool or not, you should have either a noinst_LTLIBRARIES or noinst_LIBRARIES list of targets, respectively. This should only include the name of your library (libEncoding2.la or libEncoding2.a.)
You should never use a full path for this, and you should not quote Make variables, so what you were looking for is
MyApp_CPPFLAGS = -I$LOCATION
MyApp_LDADD = libEncoding2.la # or .a
And that would work.
But on the other hand it seems like you should take some time to understand how autotools work, as it might not be what you're looking for. With a grain of salt you can take my Autotools Mythbuster as a starting point.
I have a Coq project with its libraries organised into subdirectories, something like:
…/MyProj/Auxiliary/Aux.v
…/MyProj/Main/Main.v (imports Auxiliary/Aux.v)
When I compile the files, I expect to do so from working directory MyProj (via a makefile). But I also want to work on the files using Proof General/Coqtop, in which case the working directory is by default the directory in which the file lives.
But this means that the LoadPath is different between the two contexts, and so the logical path needed for the library import is different. How do I set up the coqc invocation, the LoadPath, and the import declarations so that they work in both contexts?
Each approach I have tried, something goes wrong. For instance, if I compile Aux.v by invoking
coqc -R "." "MyProj" Auxiliary/Aux.v
and import it in Main.v as
Require Import MyProj.Auxiliary.Aux.
then this works when I compile Main.v with
coqc -R "." "MyProj" Main/Main.v
but fails in Coqtop, with Error: Cannot find library MyProj.Auxiliary.Aux in loadpath. On the other hand, if before the Require Import I add
Add LoadPath ".." as MyProj.
then this works in Coqtop, but fails under coqc -R "." "MyProj" Main/Main.v, with
Error: The file […]/MyProj/Auxiliary/Aux.vo contains library
MyProj.Auxiliary.Aux and not library MyProj.MyProj.Auxiliary.Aux
I’m looking for a solution that’s robust for a library that’s shared with collaborators (and hopefully eventually with users), so in particular it can’t use absolute file paths. The best I have found for now is to add emacs local variables to set the LoadPath up when Proof General invokes Coqtop:
((coq-mode . ((coq-prog-args . ("-R" ".." "MyProj" "-emacs")))))
but this (a) seems a little hacky, and (b) only works for Proof General, not in Coqide or plain Coqtop. Is there a better solution?
Allow me to side-step your question by suggesting an alternative process, hinted at by Tiago.
Assuming that your project's tree looks like this:
MyProj/Auxiliary/Aux.v
MyProj/Main/Main.v
In MyProj, write a _CoqProject file listing all your Coq files
-R . ProjectName
Auxiliary/Aux.v
Main/Main.v
When you open one of these Coq files, emacs will look for the _CoqProject and do-the-right-thing (tm).
As shown by Tiago, coq_makefile will also give you a Makefile for free.
I know you explicitly asked for something that works across different platforms, but there's already a Proof-General-specific solution that is less hacky than the one you have. Proof General has a special variable called coq-load-path that you can set with local variables, much like you did for coq-prog-args. The advantage is that you don't have to worry about any other arguments that need to be passed to coqtop (such as -emacs in your example). Thus, your .dir-locals.el file could have a line like this:
((coq-mode . ((coq-load-path . ((".." "MyProj"))))))
Unfortunately, I am not aware of anything that works across platforms, although I'm pretty sure that something specific for CoqIDE must exist. If this is the case, maybe you could set up a script to keep these configuration files updated across different platforms?
If you use coq_makefile you can install the library in your system.
Without OPAM
To initialize your project:
coq_makefile -f _CoqProject -o Makefile
Share your library with other projects:
make install
With OPAM
Assuming you have OPAM installed, you can use coq-shell to help you take care of dependencies.
To setup your project:
coq_shell_url="https://raw.githubusercontent.com/gares/opam-coq-shell/master/src/opam-coq"
curl -s "${coq_shell_url}" | bash /dev/stdin init 8.4 # Install Coq and its dependencies
eval `opam config env --switch=coq-shell-8.4` # Setup the environment
coq_makefile -f _CoqProject -o Makefile # Generates the makefile
opam pin add coq:YOURLIBRARY . # Add your library to OPAM
When you update your library you should do:
opam upgrade coq:YOURLIBRARY
Here is an example of a project that uses the OPAM method:
https://bitbucket.org/cogumbreiro/aniceto-coq/src
I use Eclipse CDT to auto generate make files. Now I've added some make flags to create coverage information which results in *.gcno files being created when building. When cleaning my project only *.d and *.o files are removed. What I wonder is how to extend clean to also remove *.gcno files while still letting Eclipse auto generate my make files.
Cheers,
Ceqvi
I had the same problem, and you gave me an idea that works much better:
In Makefile.targets:
clean: clean-gcov
clean-gcov:
-$(RM) $(foreach subdir,$(SUBDIRS),$(wildcard $(subdir)/*.gcda) $(wildcard $(subdir)/*.gcno))
Running it:
$ make clean
rm -rf src/Hello.gcda src/Hello.gcno
rm -rf ./src/test/HelloTest.o ./src/Hello.o ./src/test/HelloTest.d ./src/Hello.d test
I have a gtk project and I want to use gtags for my project. I also would like to use gtags for the external libraries, in my case gtk. I tried:
find /usr/include/gtk-2.0 -name "*.h" > gtk_headers
gtags -f gtk_headers
Unfortunately, I get a segmentation fault here (using Ubuntu 12.04)
Any ideas how to get this work? (I am also happy with a solution with ctags or etags).
Please try this:
$ (cd /usr/include/gtk-2.0; gtags) # make tag in the library project
$ gtags # make tag in your project
$ GTAGSLIBPATH=/usr/include/gtk-2.0; export GTAGSLIBPATH
$ global -x xxx
If 'xxx' exists in your project, global show it.
Otherwise, if 'xxx' exists in the library projects,
global show it.
To show both of them, please try this:
$ GTAGSTHROUGH=; export GTAGSTHROUGH
If you have many libraries then please specify them like PATH environment
variable.
$ GTAGSLIBPATH=/usr/src/lib:/usr/include/gtk-2.0; export GTAGSLIBPATH
Good luck!