[GenABEL-dev] m4_ax_prog_cxx_mpi.m4
L.C. Karssen
lennart at karssen.org
Fri Oct 31 09:51:51 CET 2014
Hi Alvoro,
On 30-10-14 21:59, Frank, Alvaro Jesus wrote:
> Hi Lennart, Thank you for all the info provided so far.
You are most welcome!
>
> The problem at the moment is this.
>
> there are 2 different computers with 2 different setups. One where I
> work and one were the user installs the program.
Indeed, that's the real life situation. In fact, real life is two
developers (you, me) and an unknown number of users (well, for now only
a few in München). One of the main points of Autotools is to get rid of
the problem of much scientific software: the "only works on my machine"
syndrome.
>
> The one were the user installs the program has blas, boost etc. The
> one that generates the until now unseen dist tar has a different
> setup than the user computer. SO one computer (developer) and many
> user computers (run). Is this correct?
Yes.
> 1) @Developer computer, make
> distcheck, then ----> give tar to user ---->2) user compiles and
> installs
>
Correct.
> How does that workflow work? my dist check fails because it asks me
> for blas, but there is no need to have blas at point 1) only the
> users blas is relevant at 2).
You are in right about the BLAS not being necessary for creating the
tar. If you just want to create the tar.gz file a 'make dist' is enough.
The reason why I always run 'make distcheck' is because it also runs
'make check' and some other checks (the so-called VPATH build). The main
reason for this VPATH build is to make sure all required files are
included in the Automake files (and thus in the tar.gz), and that all
files are properly cleaned up (so that 'make uninstall' works as expected).
Therefore, because I have now tested 'make distcheck' and found it to
work, you can simply run 'make dist' to create the source tar-ball to
give to your test users.
>
> Am I suppose to do dist check on the same setup as the user will
> have?
No. The idea is exactly that if the developer did his job well, all
should work if the user has the required libraries installed. If the
user doesn't have a certain library, ./configure should complain (with
an informative message).
> Why is dist check asking me for libraries and all?
'make distcheck' should find them if they are in the default locations.
You haven't yet answered my question about the location of your custom
compiled BLAS lib. Is it indeed in ../libs/include or ./libs/include?
>
> Have you tried yourself doing the dist check to make it and then give
> that tar to someone and have that someone install it?
Yes I did (with the two people being myself, but that shouldn't matter).
However, only with Ubuntu systems. I'll try to test it on a FreeBSD
system next week, if I have the time.
Best,
Lennart.
>
> I am wondering because it seems to me that we are talking about 2
> complete different approaches here.
>
> -Alvaro
>
> ________________________________________ From: L.C. Karssen
> [lennart at karssen.org] Sent: Thursday, October 30, 2014 8:46 PM To:
> Frank, Alvaro Jesus; genabel-devel at lists.r-forge.r-project.org Cc:
> juergen.riegel at helmholtz-muenchen.de Subject: Re:
> m4_ax_prog_cxx_mpi.m4
>
> Hi Alvaro,
>
> On 30-10-14 15:31, Frank, Alvaro Jesus wrote:
>> I am really not an autoconf user, but I am failing to do the make
>> distcheck. I do have openblas. I am struggling as I am not the
>> sysadmin. The end user IS the sysadmin.
>
> Not always. From my experience with ProbABEL I know many aren't.
> That's another reason to be happy with Autotools, it allows people
> not only to specify where to find libraries, but also where to
> install: ./configure --prefix=$HOME/myprograms/AOnoMM/ or, with even
> more detail: ./configure --prefix=/my/install/path
> --sysconfdir=/my/install/path/ \ --datarootdir=/my/install/path
> --docdir=/my/install/path/doc
>
>>
>> I am having trouble grasping this: They will choose the
>> openblas,boost ,gcc,mpi,etc, path right?
>
> The don't have to, but they can, see my other e-mail.
>
>>
>> So cant they just checkout the src and compile and obtain the
>> binary normally?
>
> Experienced people can do that too. There shouldn't be much
> difference. However, I wouldn't call that 'normally'. I'd say that
> this is the way people install software on their Linux system, most
> commonly used first: 1) via distro package manager from default
> repositories 2) via distro package manager from alternative
> repositories 3) by downloading the released source.tar.gz file and
> running ./configure && make && sudo make install (actually, this is
> what is listed in the INSTALL file) 4) using 3, but with their own
> ./configure options 5) checkout from a VCS (either the latest/trunk
> or a tagged release)
>
>
>
>
>>
>> My error:
>>
>> make distcheck { test ! -d "omicabelnomm-0.1.0" || { find
>> "omicabelnomm-0.1.0" -type d ! -perm -200 -exec chmod u+w {} ';' &&
>> rm -fr "omicabelnomm-0.1.0"; }; } test -d "omicabelnomm-0.1.0" ||
>> mkdir "omicabelnomm-0.1.0" test -n "" \ || find
>> "omicabelnomm-0.1.0" -type d ! -perm -755 \ -exec chmod u+rwx,go+rx
>> {} \; -o \ ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o
>> \ ! -type d ! -perm -400 -exec chmod a+r {} \; -o \ ! -type d !
>> -perm -444 -exec /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/install-sh -c -m a+r
>> {} {} \; \ || chmod -R a+r "omicabelnomm-0.1.0"
>> tardir=omicabelnomm-0.1.0 && /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar chof
>> - "$tardir" | GZIP=--best gzip -c >omicabelnomm-0.1.0.tar.gz { test
>> ! -d "omicabelnomm-0.1.0" || { find "omicabelnomm-0.1.0" -type d !
>> -perm -200 -exec chmod u+w {} ';' && rm -fr "omicabelnomm-0.1.0";
>> }; } case 'omicabelnomm-0.1.0.tar.gz' in \ *.tar.gz*) \ GZIP=--best
>> gzip -dc omicabelnomm-0.1.0.tar.gz | /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar xf -
>> ;;\ *.tar.bz2*) \ bzip2 -dc omicabelnomm-0.1.0.tar.bz2 | /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar xf -
>> ;;\ *.tar.lzma*) \ lzma -dc omicabelnomm-0.1.0.tar.lzma | /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar xf -
>> ;;\ *.tar.xz*) \ xz -dc omicabelnomm-0.1.0.tar.xz | /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar xf -
>> ;;\ *.tar.Z*) \ uncompress -c omicabelnomm-0.1.0.tar.Z | /bin/sh
>> /home/alvaro.frank/omicabelnomm/OmicABELnoMM/missing --run tar xf -
>> ;;\ *.shar.gz*) \ GZIP=--best gzip -dc omicabelnomm-0.1.0.shar.gz |
>> unshar ;;\ *.zip*) \ unzip omicabelnomm-0.1.0.zip ;;\ esac chmod -R
>> a-w omicabelnomm-0.1.0; chmod a+w omicabelnomm-0.1.0 mkdir
>> omicabelnomm-0.1.0/_build mkdir omicabelnomm-0.1.0/_inst chmod a-w
>> omicabelnomm-0.1.0 test -d omicabelnomm-0.1.0/_build || exit 0; \
>> dc_install_base=`CDPATH="${ZSH_VERSION+.}:" && cd
>> omicabelnomm-0.1.0/_inst && pwd | sed -e 's,^[^:\\/]:[\\/],/,'` \
>> && dc_destdir="${TMPDIR-/tmp}/am-dc-$$/" \ && am__cwd=`pwd` \ &&
>> CDPATH="${ZSH_VERSION+.}:" && cd omicabelnomm-0.1.0/_build \ &&
>> ../configure --srcdir=.. --prefix="$dc_install_base" \ \ && make
>> \ && make dvi \ && make check \ && make install \ && make
>> installcheck \ && make uninstall \ && make
>> distuninstallcheck_dir="$dc_install_base" \ distuninstallcheck \ &&
>> chmod -R a-w "$dc_install_base" \ && ({ \ (cd ../.. && umask 077 &&
>> mkdir "$dc_destdir") \ && make DESTDIR="$dc_destdir" install \ &&
>> make DESTDIR="$dc_destdir" uninstall \ && make
>> DESTDIR="$dc_destdir" \ distuninstallcheck_dir="$dc_destdir"
>> distuninstallcheck; \ } || { rm -rf "$dc_destdir"; exit 1; }) \ &&
>> rm -rf "$dc_destdir" \ && make dist \ && rm -rf
>> omicabelnomm-0.1.0.tar.gz \ && make distcleancheck \ && cd
>> "$am__cwd" \ || exit 1 checking for a BSD-compatible install...
>> /usr/bin/install -c checking whether build environment is sane...
>> yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking
>> for gawk... gawk checking whether make sets $(MAKE)... yes checking
>> whether to disable maintainer-specific portions of Makefiles...
>> yes checking for mpic++... mpic++ checking whether the C++ compiler
>> works... yes checking for C++ compiler default output file name...
>> a.out checking for suffix of executables... checking whether we are
>> cross compiling... no checking for suffix of object files... o
>> checking whether we are using the GNU C++ compiler... yes checking
>> whether mpic++ accepts -g... yes checking for style of include used
>> by make... GNU checking dependency style of mpic++... gcc3 checking
>> dependency style of mpic++... (cached) gcc3 checking for gcc...
>> gcc checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes checking for gcc option to
>> accept ISO C89... none needed checking dependency style of gcc...
>> gcc3 checking dependency style of gcc... (cached) gcc3 checking for
>> gcc option to support OpenMP... -fopenmp checking for library
>> containing pthread_mutex_init... none required checking for library
>> containing __iso_c_binding_c_f_pointer_l4... -lgfortran checking
>> for library containing cblas_sgemm... no configure: error: OpenBLAS
>> library NOT found make: *** [distcheck] Error 1
>>
>
> I assume you have your own BLAS compiled somewhere. Now the thing is
> that you somehow have to influence how './configure' is run by 'make
> distcheck'. This can be done as follows:
>
> DISTCHECK_CONFIGURE_FLAGS="--disable-latex-doc
> --disable-silent-rules" make -j4 distcheck
>
> So, once we've set up a proper way to add the location of a BLAS
> library (see my previous e-mail: via the Autoconf Archive macros), it
> should be a matter of specifying the right configure option. For now
> you I think (but didn't test) you should specify all CPPFLAGS,
> something like this:
>
> DISTCHECK_CONFIGURE_FLAGS="CPPFLAGS='-O3 -std=c++11 -march=native
> -mfpmath=sse -flto -funroll-loops -I/path/to/your/BLAS'" make -j4
> distcheck
>
>
>
> Best,
>
> Lennart.
>
>> ________________________________________ From: L.C. Karssen
>> [lennart at karssen.org] Sent: Thursday, October 30, 2014 3:23 PM To:
>> Frank, Alvaro Jesus; genabel-devel at lists.r-forge.r-project.org
>> Subject: Re: m4_ax_prog_cxx_mpi.m4
>>
>> Hi Alvaro,
>>
>> On 30-10-14 15:16, Frank, Alvaro Jesus wrote:
>>> Hi Lennart,
>>>
>>> Can we include m4_ax_prog_cxx_mpi.m4 on the root directory with
>>> our svn?
>>
>> We can. I'm not too much a fan of including code that is
>> maintained elsewhere and packaged properly by Linux distributions,
>> but if you think it might otherwise deter people from contributing,
>> be my guest.
>>
>> But keep in mind that a user shouldn't need to have that file
>> (because autoreconf will include it in the ./configure script,
>> which is packaged in the tar.gz file). Only a developer/someone who
>> checks out from SVN/a user who runs autoreconf after unpacking the
>> source tar.gz file needs that file.
>>
>> As to the location: what do you mean with root directory? If you
>> mean the root of the OAnoMM package (pkg/OmicABELnoMM/) than it's
>> fine with me.
>>
>>
>> Lennart.
>>
>>>
>>> Best,
>>>
>>> -Alvaro
>>
>> -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen
>> Utrecht The Netherlands
>>
>> lennart at karssen.org http://blog.karssen.org GPG key ID: A88F554A
>> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
>>
>
> -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen
> Utrecht The Netherlands
>
> lennart at karssen.org http://blog.karssen.org GPG key ID: A88F554A
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
>
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands
lennart at karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20141031/cfb882bd/attachment.sig>
More information about the genabel-devel
mailing list