I just want to develop a C app in linux with the auto(make/conf/...) stuff automatically generated. I tried generating it with ede and anjuta, but it doesn't seem to generate Makefile.am. So, I tried running automake, and it says "ltmain.sh" isn't found. Is there some easy to generate the basic build files for linux C/C++ apps. What is the standard practice? Do most people write these files themselves?
Generating a really trivial set of autotool files is pretty easy. Here's a (really basic) example. After you run these, you should get a copy of ltmain.sh in the directory, and you'll be all set to run the configure script:
$ mkdir sample
$ cd sample
$ echo 'int main( void ) { return 0; }' > foo.c
$ echo 'bin_PROGRAMS = foo' > Makefile.am
$ autoscan
$ mv configure.scan configure.ac
$ # edit configure.ac, add AM_INIT_AUTOMAKE([foreign])
$ # and LT_INIT, set project name and bug-report-address
$ autoreconf -ivf
Note that in this example, libtool really isn't necessary since
the example is just building a simple app. But you asked about
ltmain.sh, and that's a libtool thing so LT_INIT is needed to
address that portion of the question. If you want to build
a library, change bin_PROGRAMS to lib_LTLIBRARIES.
EDE can work with your Automake files in two different ways. If you write your own automake files, it will read them, and tweak them via the UI.
If you prefer, you can have EDE do the whole thing for you. First, create your first C file, then when it is on disk, do:
M-x ede-new RET Automake RET
then from the project/project options menu, add a target, like "program".
If you fill in your C file, you can then choose Project->Build->build currentproject from the menu, and it will create and setup everything needed for Automake to do it's thing, in addition to running all the misc automake commands needed.
Lastly, there is a 'run' option somewhere to run your program.
I'd consider not using autoconf and automake at all -- their complexity outweighs their benefit, particularly if you're targeting only Linux.
Note that "git", for example, doesn't use them at all; instead it simply has a moderately-complex (but comprehensible) Makefile.
Related
I want to do collision detection in MATLAB. In MATLAB its possible to include a shared library written in C with
loadlibrary();
I found a collision detection library written in C:
https://github.com/danfis/libccd
The documentary says that
mkdir build && cd build
cmake -G "Unix Makefiles" -DBUILD_SHARED_LIBS=ON ..
make && make install
build libccd as a shared library. After execute these commands in terminal I get a libccd.dylib. Thats what I need for MATLAB...
loadlibrary('libccd');
But MATLAB wants a header file (or more than one) in addition to the shared library.
https://www.mathworks.com/help/matlab/ref/loadlibrary.html
So I added the ccd.h file to the loadlibrary command. Then the problem is that ccd.h includes another header file but in an under folder: ccd/vec3.h
It seems that MATLAB has a problem with this.
So my questions are:
I don't know if the ccd.h file is the correct file to link first. Which one should I use?
How to resolve the problem that MATLAB can not find a file in another path
I don't know what
mkdir build && cd build
cmake -G "Unix Makefiles" -DBUILD_SHARED_LIBS=ON ..
make && make install
does. Maybe I should build a shared library my own. But I am not a programmer and never worked with Cmake, Makefiles and so on.
Thanks for every help
I think you need to use the 'addheader'option to loadlibrary.
loadlibrary('libccd', 'ccd.h', 'addheader', 'ccd/vec3')
Rinse and repeat for all the headers it needs.
Now that I am moving on from Software Foundations where everything is served on a platter I am having trouble figuring out how to set up my own projects. There are some instructions out there, but since I am just starting out I find this too complex when trying to set up a hello world program. Also I have some other issues.
hello.v
The way I've managed to compile an empty hello.v is by putting the above in the _CoqProject file and then running...
coq_makefile -o Makefile.coq -f _CoqProject
This makes the makefiles.
make -f Makefile.coq
This compiles the project, but I can't get make hello to work with just this and Proof General happens to use this when compiling individual files.
make hello.vo
make: *** No rule to make target 'hello.vo'. Stop.
The above is what I get when I try compiling from Proof General.
What should I do here? What would be the simplest possible way to set up a project with an empty file for use with Proof General + Emacs?
-Q . VFA
Also, why does SF vol 3 work despite not having much in its _CoqProject file? It only has the above.
2022 Update
There is a template to create new projects and to generate the associated boilerplate: https://github.com/coq-community/templates
Original answer
Here's what a conventional setup looks like (it's not actually standardized, you will find variations in the wild, especially for old projects, and future projects with dune now supporting Coq):
_CoqProject
Makefile
theories/
hello.v
With the following _CoqProject:
-Q theories/ MyProject
theories/hello.v
# list paths to .v files here
In particular, qualifying the project (-Q path/ ProjectName) avoids ambiguities (if the same module name is used elsewhere) and makes it easier to import from other projects later.
And the following Makefile:
build: Makefile.coq
$(MAKE) -f Makefile.coq
Makefile.coq: _CoqProject
coq_makefile -f _CoqProject -o Makefile.coq
.PHONY: build
The build target is marked .PHONY to indicate that it's not meant to create a file/directory. This avoids problems when other tools create a build directory for whatever reason.
Command line
To build the whole project from the command line, type make (which is equivalent to make build by default because build is the first command of the Makefile).
To build only one .vo file, for example theories/hello.vo, type make -f Makefile.coq theories/hello.vo. It must be listed in the _CoqProject (so that coq_makefile then puts it into Makefile.coq.conf).
Proof General
In Proof General there is an option "Compile Before Require", which does as its name says. (Coq > Auto Compilation > Compile Before Require)
The coq-Compile command you seem to have been using appears abandoned given its current lack of configurability. coq-Compile calls make hello.vo, but there is no hello.vo target in the Makefile, which is the one make looks at by default, unless the -f option is set. One way to make this PG command work with that setup is to include the generated Makefile.coq inside the Makefile:
# Add this line to Makefile to enable PG's "coq-Compile"
-include Makefile.coq
I'm personally hesitant to do that because I don't really understand what's in Makefile.coq.
Also, why does SF vol 3 work despite not having much in its _CoqProject file? It only has the above.
All SF volumes work that way now. For interactive editing with Proof General/CoqIDE, only the -Q option matters (actually, -R and a few others too), not the filenames. The filenames are used by coq_makefile, but you could also change the invocation of coq_makefile to get the filenames from elsewhere, for example as direct command line arguments:
# If _CoqProject only contains the -Q option
coq_makefile -f _CoqProject theories/hello.v
Many Coq libraries on github does not provide install guides / etc. documentation. Maybe there are general way / ways to install such libraries? For example, x86proved https://github.com/nbenton/x86proved How to install this?
There is no way to tell. But as a rule of thumb, you should look for files of three different forms:
Make
Makefile
_CoqProject (for recent developments)
Depending on these conditions, You can try one of the following solutions.
If there is a Make file, then you should read the documentation of the coq_makefile command. For instance, typing the following sequence of commands will be meaningful, most of the time:
coq_makefile -f Make -o Makefile.coq
make -f Makefile.coq
make -f Makefile.coq install
If there is already a file named F that has makefile as a substring, then I would try
make -f F
make -f F install
If there is a _CoqProject file, then follow the same instructions as 1/ above.
If none of the above cases applies, then I would try the following:
ls *.v > MyMake
coq_Makefile -f MyMake -o Makefile.coq
and then proceed as in case 1/ above.
You should also check whether your pet project is available in the coq opam archive. When this is the case this repository contains tested installation instructions, in a somewhat advanced syntax. At the date of writing these lines, this does not apply for Nick Benton's x86proved.
I hope this helps. I have not tried on Nick Benton's development, but it appears that the README.txt file says that the sources are in the src subdirectory. In turn, the src subdirectory contains a Makefile, so I would proceed as indicated above. Please keep us informed of your progress, your experience will be valuable for other developers.
I know no Perl, so please be patient!
This is a bit from the script, that generates the error:
if (-x '/usr/bin/gcc') {
$gcc = Fink::Services::enforce_gcc(<<GCC_MSG);
Under CURRENT_SYSTEM, Fink must be bootstrapped or updated with gcc
EXPECTED_GCC, however, you currently have gcc INSTALLED_GCC selected.
This typically is due to alteration of symlinks which were
installed by Xcode. To correct this problem, you will need
to restore the compiler symlinks to the configuration that
Apple provides.
GCC_MSG
$gcc = "-gcc" . $gcc;
}
This script installs fink package manager on Macs. (I'm not a Mac user, trying to help out my friend to install a program that is originally a GNU program and needs to be compiled from sources).
The install script complains about the version of GCC being not what it expects. I suspect that this is the place that fails, but don't quite understand what is it doing.
I've tried creating a symlink to the installed GCC, which is version 4.2.1, while fink wants version 4.2.
This message is displayed if I put a symlink to GCC into /usr/bin. Otherwise it identifies the version of GCC properly and refuses to install.
I thought that -x switch is similar to Bash and means that it is checking that the file is an executable, but I'm not sure what exactly does it do in Perl and would it treat a link to an executable as executable?
Thanks!
it test is the file has the executable bit set.
in your case: chmod -x /usr/bin/gcc will cause your if block to no execute.
chmod +x /usr/bin/gcc will casue your if block to get execute.
Perl's file test operators (you can see the documentation using the command: perldoc -f -x) usually do follow symlinks, with the exceptions of -l and lstat(). If you specifically want to test the link rather than the target, you can first do one of those, and then test -x _; _ as an argument makes it reuse the last stat results.
-X File is executable by real uid/gid
I'm writing Perl t/*.t tests for an existing project. During development, I'd like to use 'prove' to run select tests at arbitrary depths in the module directory hierarchy. I've created some t/ directories at the same depth as the *.pm files I'd like to test. Unfortunately, the lib/ at the base of the project's code is not in #INC.
What's the best way to automatically detect and add the path to #INC? I've looked at the -b option to prove and blib in general but they don't seem to work (they take the pwd and append blib/lib to it and add that to #INC). Ideally, the solution would not require an environment variable or installing the modules and would accommodate a number of working copies of the same code.
Is my approach wrong? Is there something obvious I'm missing? CPAN modules seem to solve this through installation or copied code blocks at the top of *.t files (yuck).
Edit:
Structure looks like:
/home/user/proj/branch\_foo/lib/First/Second/Third.pm
/home/user/proj/branch\_foo/lib/First/Second/t/third.t
This works:
~/proj/branch\_foo/lib/First/Second$ prove -I../..
But I'd like:
~/proj/branch\_foo/lib/First/Second$ prove -r
Or:
~/proj/branch\_foo/lib/First/Second$ prove t/third.t
So I can do:
~/proj/branch\_foo/lib$ prove -r
Instead of:
~/proj/branch\_foo/lib$ prove -I. -r
Maybe I just have to use -I and deal with it.
prove has an -I command line option:
-I Library paths to include.
Can you specify the paths using that option?
Update:
Thanks for providing the layout. I cannot think of a quick solution right now, but maybe you can use .proverc files in the appropriate directories to cut down on the typing required. I am not sure how multiple .proverc files interact with the -r option but this is something to look into.
This is exactly why the blib module exist. It looks in the current directory then its parent directories looking for blib/lib to add to #INC. It's part of the Perl standard library, so you should already have it.
From somewhere under t/ you can use the -M switch to load blib:
% perl -Mblib test.t
If you want to use it with prove
% perl -Mblib prove test.t
I think that's supposed to be the same thing as the -b switch in prove, but that last time I tried it (long, long ago) it didn't work. Maybe they've fixed it to work like blib.pm:
% prove -b test.t
Note that this requires you to build your distro first rather than test from lib/, but you should be doing that anyway. :)
You can set the environment variable PERL5LIB (as described in perldoc perlrun) which will cause perl to prepend the colon-separated paths to your #INC:
% export PERL5LIB=/absolute/path/to/your/libraries
% cd into/part/of/your/test/suite
% prove -r