autoconf-archive-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ax_code_coverage results in non-portable makefile


From: Simon Sobisch
Subject: ax_code_coverage results in non-portable makefile
Date: Sun, 5 Nov 2017 19:47:19 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Dear Autoconf archive maintainers,
dear last editors of ax_code_coverage.

GnuCOBOL uses ax_code_coverage.m4 and we're happy with the options it
provides. But we currently always have to deactivate the parts before
running `make dist` as the resulting tarball don't work with either
Solaris Make or other make implementations that don't provide the
extensions of GNU Make.
As the main purpose of automake is to generate portable Makefiles by
default this is really sad.


I've wrote to Bastien Roucaries as the last changing person mid 2017 and
he wrote to this list about a possible solution but the answer seems to
be missing on the archive.
I've also seen Reini Urban starting to fix similar issues with
ax_valgrind_check.m4 but again no answer on the archive.

Can anybody please suggest a possible solution?

A workaround would be to change the generation of the Makefiles during
`make dist` (this way the people building from vcs will have full
lcov/valgrind options [and needing GNU Make], while people building from
a dist tarball would have a portable package [without these options]),
but a manual change with sed/patch via a manual dist-hook seems like a
bad idea...

If using the GNU Make extensions is needed for creating the Makefiles
that are the result of `--enable-code-coverage` and `--enable-valgrind`
this would be fine, too, but having non-portable Makefiles when these
options aren't used is not nice.

GnuCOBOL is shortly before the release-candidate of the next version and
I'd like to have another solution then temporarily removing the parts
for the code coverage checks (which was needed for the last release).

Thank you for your answer,
Simon Sobisch


Am 11.08.2017 um 15:56 schrieb Bastien ROUCARIES:
> I have a solution but it will break other use...
> 
> It is cleaner I am waiting head of project
> 
> On Wed, Aug 9, 2017 at 9:53 PM, Simon Sobisch <address@hidden> wrote:
>> Hello Bastien,
>>
>> just a friendly ping.
>> Did you got any responses? Do you have a solution already?
>>
>> Simon
>>
>> Am 25.07.2017 um 22:08 schrieb Bastien ROUCARIES:
>>> Hi,
>>>
>>> I forward a message about ax_code_coverage.
>>>
>>> I could fix it by a quick and dirty change but I believe the problem
>>> is more general.
>>>
>>> The solution is to use ax_am_macros_static that will allow to add some
>>> custom rules.
>>>
>>> But it will need to change   @CODE_COVERAGE_RULES@ to
>>> to include $(top_srcdir)/aminclude_static.am
>>>
>>> What do you think ?
>>>
>>> Bastien
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Simon Sobisch <address@hidden>
>>> Date: Fri, Jul 14, 2017 at 9:39 AM
>>> Subject: GnuCOBOL needs your help: ax_code_coverage resulting in
>>> non-portable makefile
>>> To: "\"Bastien ROUCARIÈS\"" <address@hidden>
>>>
>>>
>>> Hello Bastien,
>>>
>>> we've added the recent version of ax_code_coverage.m4 to GnuCOBOL
>>> (shortly before our planned release) and it works like a charm.
>>> The problem arizes now as we test the release tarball - and it doesn't
>>> even `make` on Solaris any more. The "obvious" problem are the "=?"
>>> included because of the code coverage parts just removing them leads
>>> to more strange errors.
>>>
>>> Can you please advise how to remove the code coverage parts during
>>> `make dist`? It would be nice to keep it in and only skip the
>>> offending parts when Solaris' make is invoked but I wouldn't have any
>>> idea how to do this.
>>> Thank you for taking the time to answer,
>>>
>>> Simon
>>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]