[GenABEL-dev] LATEX error on autoreconf
L.C. Karssen
lennart at karssen.org
Mon Oct 27 13:06:51 CET 2014
Hi Alvaro,
On 27-10-14 12:39, Frank, Alvaro Jesus wrote:
> If I understand correctly users can install omicabellnomm from
> somewhere else.
Yes, indeed.
> Can I get info on how to do this? I will stop all
> installation and deployment of omicabelnomm at Helmholtz and the
> local sysadmin will be forwarded to that procedure. It will be a
> good test case.
The idea of autotools is not only that it makes life for the developer
easier (which it sometimes doesn't ;-)), but also that programs can be
more easily distributed, also to other UNIX platforms.
So the proper workflow is the following:
- Developer writes code, and creates configure.ac/Makefile.am files.
- Before a new version is released, (s)he runs 'make check' for all
functional tests, followed by 'make distcheck' to check whether
installation actually works even when the source location is read-only
(a so-called VPATH build). This really makes sure that the
autoconf/automake code was written well. NOTE: currently 'make
distcheck' fails for OmicABELnoMM because of the LaTeX documentation
part. I still need to fix that.
- Next, the developer runs 'make dist', which creates a tar.gz file that
is the official released source code. This is the file you will post on
the website. You can decide to sign it using your GPG key as well, if
you want to allow people to ascertain that they have a legitimate tar.gz
file.
- A user/sysadmin will download the tar.gz file from the Downloads
section of the project's website and untars it.
- Next it's a matter of running the ./configure, make, make install
sequence to get stuff installed.
The whole idea of autoconf and automake is that they generate the files
'configure' (a large shell script that checks whether the user has the
requirements needed to build the project) and 'Makefile' (which
streamlines the compilation and installation steps). Because the 'make
dist' step adds these two files to the tar.gz file you distribute, the
user doesn't need to have autoconf/automake installed, but of course
(s)he needs to have the proper compiler(s), libraries, etc. installed.
Additionally, package maintainers for Linux distros (those who create
.deb/.rpm files) love packages that use autotools because their package
building systems are tuned to those kind of package, allowing them to
easily and uniformly insert their own compiler flags (e.g. for
hardening) and install the files where they want (instead of the default
/usr/local/.../ directories).
>
> I propose a workflow change: One branch for me to develop on, and one
> branch with release code. /develop /release
That would indeed be the best. Ideally 'trunk' (in which we are working
now) should always contain 'releasable' code and any development should
be done in branches which are merged with trunk whenever ready. We
currently don't adhere to that policy. For some larger projects in
ProbABEL I did create branches, e.g. the one in which I fixed problems
with the Cox regression module, or the one I used for the implementation
of p-value calculation.
Since you are the maintainer of OmicABELnoMM I leave it up to you to
define the rules for OmicABELnoMM. If you'd like to create a
OmicABELnoMM main development branch: go ahead! See
http://genabel.r-forge.r-project.org/tutHowToMakeTags.html for a brief
intro on how to make branches. Be sure to also read the SVN docs on
merging branches into trunk (if you haven't already done so).
>
> On the develop branch I wont have to deal with autoconf in the least
> and just focus on features + bug fixing. autoconf will no longer
> break my environments, and users will be forwarded to /release for
> installation. If their system gives them errors regarding source
> code, I will deal with it under develop, merging later to /release.
This part I don't get. I'd say that whatever you develop should also
take autotools into account. For example, using the Boost libraries is
great, but without a proper check in configure.ac (and possibly some
compiler flags etc. in Makefile.am) the other developers would not know
they are missing a library. Moreover, for a correctly working
./configure && make && make install run (by the user or other
developers) you need to have proper autotools checks in place. Otherwise
everybody needs to hunt for the required libraries/compiler flags/header
files themselves.
Of course, while working in a given development branch you can focus on
the functionality and only when you are satisfied with the results add
whatever autotools magic is needed (that's the way I usually do it). And
when you're satisfied that 'make distcheck' works for all
options/possibilities, you merge the development branch into trunk and
you are ready for a new release.
> If the users have problems with autoconf, they will be forwarded to
> the mailing list.
Yes. Because apart from small bugs, the users should only have to run
./configure
Or, if they don't have root permissions:
./configure --prefix=/home/username/my_compiled_programs/OmicABELnoMM/
Or if they don't need MPI, for example:
./configure --without-mpi
Or if they don't need MPI and don't have LaTeX installed:
./configure --without-mpi --disable-latex-doc
See ./configure --help for all options.
Followed by
make
make check # (not really required, usually)
make install
I hope this explanation makes things clearer. Please let me know if
something is still unclear.
Lennart.
>
> Is this reasonable?
>
> -Alvaro ________________________________________ From: L.C. Karssen
> [lennart at karssen.org] Sent: Monday, October 27, 2014 12:32 PM To:
> Frank, Alvaro Jesus; genabel-devel at lists.r-forge.r-project.org
> Subject: Re: [GenABEL-dev] LATEX error on autoreconf
>
> Hi Alvaro,
>
> On 27-10-14 12:23, Frank, Alvaro Jesus wrote:
>> Hi Lennart,
>>
>> My solution was simlier, check for mpicc/mpixx and done, no need
>> for special scripts. For me as a developer it might not be a
>> problem, but I am testing user environments and I cant ask users to
>> do download those special features. Is there a way to revert it to
>> a system where a conditional check is used for mpicc/mpixx and if
>> not use normal g++?
>
> I agree with you that the average user shouldn't be bothered with
> unnecessary downloads. However, when we create a tar-ball for
> distribution (make dist), the required macros will be included (a
> user that untars the tar.gz file will not need to run autoreconf). In
> fact, neither automake, nor autoconf are required by the user. So
> there is no problem for the end user here.
>
> Of course, someone who does an SVN checkout must run autoreconf, so
> this person (which I consider to be a developer) should have
> autoconf, automake and the autoconf archives installed.
>
>
> Best regards,
>
> Lennart.
>
>>
>> -Alvaro
>>
>> For the record, any request made to user gets escalated to
>> sysadmins and then this is what happens:
>>
>>
>> --------------------------------------- Daer Mr. Frank,
>>
>> i needed some time to get it compiled, each compiling one day.
>>
>> It comes out, that for installation gcc 4.6 and 4.9 conflicts in
>> system libraries with same name.
>>
>> Due to the fact, that 223 packages depend on gcc 4.6 i can not
>> update these libraries.
>>
>> Sorry, but gcc 4.6 is highest gcc version i can provide.
>>
>> Best regards,
>>
>> -----------------------
>>
>> On Tuesday 23 September 2014 15:35:29 you wrote:
>>> Dear Mr ----------,
>>>
>>> Thank you for your help with Autoconf. I have managed to make
>>> advancements but I am in the need for a newer version of GCC,
>>> would this also be possible? 4.9 would be ok. Thank you in
>>> advance for any help on the matter!
>>>
>>> Best regards,
>>>
>>> Alvaro
>>>
>>> -----Ursprüngliche Nachricht-----
>>>
>>>
>>> Dear Mr. Frank,
>>>
>>> autoconf Version 2.69 is now installed under
>>> /opt/autoconf/2.69/bin.
>>>
>>> To use it in bash, use:
>>>
>>> export PATH=/opt/autoconf/2.69/bin:$PATH
>>>
>>> to see:
>>>
>>> autoconf --version
>>>
>>> Current standard version 2.63 could not be replaced for system
>>> stability.
>>>
>>
>>
>>
>> ________________________________________ From:
>> genabel-devel-bounces at lists.r-forge.r-project.org
>> [genabel-devel-bounces at lists.r-forge.r-project.org] on behalf of
>> L.C. Karssen [lennart at karssen.org] Sent: Monday, October 27, 2014
>> 12:17 PM To: genabel-devel at lists.r-forge.r-project.org Subject:
>> Re: [GenABEL-dev] LATEX error on autoreconf
>>
>> Hi Alvaro,
>>
>> On 27-10-14 10:30, Frank, Alvaro Jesus wrote:
>>> There is another error on a different system with the same raw
>>> checkout:
>>>
>>> user at ubuntu:~/Desktop/omicabelnomm/mergeTest/OmicABELnoMM$
>>> ./configure 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... no checking for mawk... mawk checking
>>> whether make sets $(MAKE)... yes checking whether make supports
>>> nested variables... yes checking whether make supports nested
>>> variables... (cached) yes checking whether to enable
>>> maintainer-specific portions of Makefiles... yes ./configure:
>>> line 3154: syntax error near unexpected token `test' ./configure:
>>> line 3154: `AX_PROG_CXX_MPI(test "x$with_mpi" != "xno",'
>>>
>>> Note that my system DOES have mpi and that it compiled without
>>> issues.
>>
>> That's because the AX_PROG_CXX_MPI autoconf macro is not part of
>> the default autoconf install. See the SVN log message of commit
>> 1849 for pointers on how to solve this error.
>> https://r-forge.r-project.org/scm/viewvc.php/pkg/OmicABELnoMM/configure.ac?root=genabel&view=log#rev1849
>>
>>
>>>
>>>
>>
It is difficult to solve problems if I wasn't the one introducing
>>> them.
>>
>> Indeed. But it's a good idea to review log messages of the changes
>> that were done by others ;-).
>>
>>
>>>
>>> I appreciate any help on the matter.
>>
>> Let me know if you keep having troubles with this.
>>
>>
>> Lennart.
>>
>>>
>>>
>>> -Alvaro
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>
>>>
*From:* genabel-devel-bounces at lists.r-forge.r-project.org
>>> [genabel-devel-bounces at lists.r-forge.r-project.org] on behalf of
>>> Frank, Alvaro Jesus [alvaro.frank at rwth-aachen.de] *Sent:*
>>> Monday, October 27, 2014 10:21 AM *To:*
>>> genabel-devel at lists.r-forge.r-project.org *Subject:*
>>> [GenABEL-dev] LATEX error on autoreconf
>>>
>>> Is there a reason for this to happen? (pure checkout from the
>>> repo)
>>>
>>> /opt/omicabelnomm/OmicABELnoMM> autoreconf -fi Makefile.am:194:
>>> BUILD_latexdoc does not appear in AM_CONDITIONAL
>>> Makefile.am:195: HAVE_PDFLATEX does not appear in AM_CONDITIONAL
>>> autoreconf: automake failed with exit status: 1
>>>
>>>
>>> Any help is appreciated,
>>>
>>> -Alvaro
>>>
>>>
>>>
>>> _______________________________________________ genabel-devel
>>> mailing list genabel-devel at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel
>>>
>>
>>>
>>
>>>
-- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 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/20141027/2ef0ddff/attachment.sig>
More information about the genabel-devel
mailing list