When I build a cabal project in vim, using
:set makeprg=cabal\ build
:make
haskellmode-vim doesn't seem to find the type information. Doing _t when the cursor is on foo gives me "foo type not known".
How can I get haskellmode-vim to obtain the type information from a cabal build?
Doing :GHCReload allows me to use _t and _T.
Related
I have a CMake/CTest configuration set up and all works fine. The problem is that we have one test runner that has several versions of GCC in use and for this project I'll have to use non-standard location of the compiler. So for example instead of using standard /usr/bin/gcc I'll be using /mnt/data/gcc/8.4.0/bin/gcc.
For compilation point of view everything goes well when using -DCMAKE_C_COMPILER=/mnt/data/gcc/8.4.0/bin/gcc when creating the CMake project, but when I run ctest -T coverage CTest wants to use /usr/bin/gcov which is incompatible with the compiler. How can I set the CTest to use /mnt/data/gcc/8.4.0/bin/gcov instead?
I've tried to set the value of CTEST_COVERAGE_COMMAND in CTestConfig.cmake, but it does not have any effect.
BEFORE YOU LINK TO: Using the pkg-config macro PKG_CHECK_MODULES failing
this does not solve my solution. i do have pkg-config installed. when i type aclocal --print, the first thing it gives is main::scan_file() called too early to check prototype at /usr/local/bin/aclocal line 618. it does that too in ./bootstrap.
then it gives the directory /usr/local/share/aclocal
for one or another reason, the macro still doesnt work. i am on Artix linux (an Arch like distro), with automake 1.16.2-3 and pkg-conf 1.7.3-1. the output of ./configure, config.log and ./bootstrap are: https://pastebin.com/NY1GgtFF (configure), https://pastebin.com/iDAUXRv3 (config.log) and https://pastebin.com/aRVw00Ex (bootstrap)
the macro expansion fails no matter what. do you have any ideas? how would i set the m4_pattern_allow flag? this error occurs both at openbox, and lxterminal. i havent tried any other programs yet where i encounter this error, but i dont think it matters at which program it happens
i really hope i provided enough information, this is my first post, so i hope i did everything right
pkg-conf is not the same as pkg-config — the former is a low-deps reimplementation and does not come with the pkg.m4 file you need to have the macro installed.
If the software you're trying to build comes with a copy of pkg.m4 bundled in the repository and/or tarball, you may just need to add -I m4 to the invocation of aclocal, otherwise you need to fetch the pkg.m4 file from a pkg-config distribution.
I need to build gcc-4.3.4 in a non-standard location (NFS mounted). I configured:
../gcc-4.3.4/configure --prefix={install dir} --with-gmp={install dir} --with-mpfr={install dir} --with-local-prefix={install dir} --disable-shared
I ran make -j1. But I keep getting:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
In x86_64-unknown-linux-gnu/libgcc/config.log, I can see:
/home/panthdev/apps/gcc-4.3.4-compliant/compiler/objdir/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
libmpfr.so.1 is there in {install dir}/lib. Also if I set LD_LIBRARY_PATH to {install dir}/lib, then it finds the libmpfr.so.1 but config.log starts complaining:
/tmp/cce9YhFK.s: Assembler messages:
/tmp/cce9YhFK.s:16: Error: bad register name `%rbp'
/tmp/cce9YhFK.s:18: Error: bad register name `%rsp'
As I read here you have 32bit binutils where as gcc is trying to do a 64bit build. Make sure your binutils & gcc has the same configuration.
You should maybe try using --with-sysroot instead of --prefix.
In the GCC 4.5.2 configure script (I have that available, but not 4.3.4), at around line 4500 (of 15.5K lines), there is the stanza:
rm -f conftest.$ac_ext
EXEEXT=$ac_cv_exeext
ac_exeext=$EXEEXT
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
$as_echo_n "checking for suffix of object files... " >&6; }
if test "${ac_cv_objext+set}" = set; then :
$as_echo_n "(cached) " >&6
else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
_ACEOF
rm -f conftest.o conftest.obj
if { { ac_try="$ac_compile"
case "(($ac_try" in
*\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
$as_echo "$ac_try_echo"; } >&5
(eval "$ac_compile") 2>&5
ac_status=$?
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; then :
for ac_file in conftest.o conftest.obj conftest.*; do
test -f "$ac_file" || continue;
case $ac_file in
*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;;
*) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
break;;
esac
done
else
$as_echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error "cannot compute suffix of object files: cannot compile
See \`config.log' for more details." "$LINENO" 5; }
fi
rm -f conftest.$ac_cv_objext conftest.$ac_ext
fi
Basically, the script is trying to compile 'conftest.c' and trying to find the extension of the object file created - and, for some reason, your compiler is not creating a conftest.o.
This isn't the first test it does on the compiler, so there seems to be something rather odd going on in your environment.
I've built GCC numerous times over the years - on Solaris and MacOS X - and I've always used the --prefix option. That is not the problem. The GMP, MPFR, MPC directories are necessary; the only option you've used that I'm not familiar with is the --with-local-prefix.
Are you specifying the bootstrap compiler somehow? Consider trying your current configure line with the addition of CC=/usr/bin/gcc or something similar, identifying a fully working compiler on your machine. I'm not convinced that'll solve the problem, but there is something funny about the way the compiler is behaving, or about the object file extensions that it produces. I assume you have several GB of spare space on the disk system? You'll need that.
Poking around the 'Installing GCC: Configuration' page, I find:
--with-local-prefix=dirname
Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.
You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.
The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.
The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)
Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.
Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.
GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.
Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).
The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.
Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.
Are you sure you're using that correctly? You probably are since you have to search to find the option -- ../gcc-4.x.y/configure --help does not mention the option.
I would like the executables for a project I am working on to have the latest mercurial changeset recorded so that when a user complains about buggy behavior, I can track which version they are using. Some of my executables are Python and others are compiled C. Is there a way to automate this, or can you point me to projects that exhibit solutions that I can look at?
I am using autoconf in my project... in case that makes the solution easier.
Thanks!
Setjmp
A common way to do this is with m4_esyscmd. For example, autoconf distributes a script in build-aux which generates a version number from the git repo and invokes AC_INIT as:
AC_INIT([GNU Autoconf], m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-autoconf#gnu.org])
You can often get away without distributing the script and do something simple like:
AC_INIT([Package name], m4_esyscmd([git describe --dirty | tr -d '\012']),
[bug-report-address])
Instead of git-describe, use whatever command you want to generate the version number. One important detail is that it should not have a trailing newline (hence the tr following git-describe).
A major drawback with this technique is that the version number is only generated when you run autoconf.
Add this to configure.ac:
AM_CONDITIONAL([IS_HG_REPO], [test -d "$srcdir/.hg"])
Add the following lines to Makefile.am:
if IS_HG_REPO
AM_CPPFLAGS = -DHGVERSION="\"$(PACKAGE) `hg parents --template 'hgid: {node|short}'`\""
else
AM_CPPFLAGS = -DHGVERSION=PACKAGE_STRING
endif
This will define HGVERSION as a string of the form APPNAME hgid: 24d0921ee4bd or APPNAME VERSION, if building from a release tarball.
See wiki page on versioning with make
I'm using scons to build a linux C based ruby extension. What is the "right" way to get the include paths right? By "right" I mean it works out of the box on 1.9 and 1.8.
I don't want to use the mkmf/Makefile solution.
Thanks! Dave
If you were using autoconf, you could borrow ruby.ac from rice:
http://github.com/jameskilton/rice/blob/master/ruby.ac
or since you are using a different build system, you can duplicate its behavior. To summarize what it does:
We use the rbconfig module to get ruby config variables like this:
$RUBY -rrbconfig -e "puts(Config::CONFIG['$1'] || '')" <variable>
where $RUBY is the ruby interpreter (sometimes interpreters get installed with a different name, e.g. ruby1.8 or ruby1.9) and <variable> is the desired config variable
We then set our build variables:
if ${ruby_config_rubyhdrdir} is empty: (e.g. ruby 1.8)
CPPFLAGS="-I${ruby_config_archdir}
else:
CPPFLAGS="-I${ruby_config_rubyhdrdir} ${ruby_config_rubyhdrdir}/${arch}
CFLAGS="${ruby_config_CFLAGS} ${ruby_config_CCDLFLAGS}"
LDFLAGS="-L${ruby_config_archdir} -L${ruby_config_libdir} ${ruby_config_LDFLAGS}"
LIBS="${ruby_config_LIBS} ${ruby_config_DLDLIBS}"
where the variables ${ruby_config_*} are determined using the config command above, e.g.:
ruby_config_foo=$RUBY -rrbconfig -e "puts(Config::CONFIG['$1'] || '')" foo
We also need to link with the ruby library, so we append ${ruby_config_LIBRUBYARG}.
The above variables are for compiling and linking; you may also need to install. Ruby library files should be installed to ${ruby_config_sitelibdir}. Ruby extensions should be installed to ${ruby_config_sitearchdir}.
There's also some magic in ruby.ac for building with mingw and linking against the one-click installer on windows (which used to be built with vc6; I'm not sure if it still is or not).