Hi Olaf,
thank you very much for your efforts. I pushed the macros
AX_PROG_{CC,FC,F77,CXX}_MPI that were attached to your e-mail
to the Autoconf Archive in this commit:
http://git.savannah.gnu.org/cgit/autoconf-archive.git/commit/?id=0f83111d8fd1f2be6603780f4da0114711ee51b6
I made a few cosme
Hi guys,
please apply the following patches to the website CVS repository to make
sure that an up-to-date URL of the Autoconf Archive homepage is used.
Thanks!
Peter
Index: autoconf.alt-pl.html
===
RCS file: /web/autoconf/autocon
Ralf Wildenhues writes:
>> I use the AX_PREFIX_CONFIG_H macro exactly the same way and it seems
>> to work fine.
>
> Which M4 versions are you two using, respectively?
I'm using Autoconf 2.61 and GNU m4 1.4.9; for me the macro works.
Hope this helps,
Peter
_
Stepan Kasal writes:
> AC_INIT([xGA], [0.1], [EMAIL PROTECTED])
> AM_INIT_AUTOMAKE([1.10])
> AC_CONFIG_HEADERS([config.h])
> AX_PREFIX_CONFIG_H
> #...
> AC_OUTPUT
I use the AX_PREFIX_CONFIG_H macro exactly the same way and it seems to work
fine. The only thing that worries me is the generat
Guido Draheim writes:
> Peter Simons writes:
>
>> Hi Julian,
>>
>> thank you for taking the time to update the macro. Your patch
>> certainly feels reasonable to me, so I applied it to the macro:
>>
>> http://autoconf-archive.cryp.to/ax_enable_
Hey Guido,
thank you for remedying the situation as promptly and as
painlessly as you did. I really appreciate how cooperative
you are. I feel it's perfectly understandable that you
accidently forgot to mention that you are re-distributing
the result of other people's efforts. Please keep up your
Introduction
At the end of 2004, I received various flames and derogatory comments about
the Autoconf Macro Archive from a handful of very vocal people, first and
foremost Guido Draheim. The gist was that I was some sort of criminal because
I distributed the macros
Stepan Kasal writes:
> There is still one problem with the macro--it changes
> prefix=NONE to prefix="$ac_default_prefix", so subsequent
> macros don't have the information whether prefix is
> defaulted or not.
> The patch attached to this mail fixes this issue.
I have applied the patch mom
Stepan,
I have applied the last patch you sent to the macro and
committed it to the archive. The complete macro looks like
this now:
dnl @synopsis AC_DEFINE_DIR(VARNAME, DIR [, DESCRIPTION])
dnl
dnl This macro _AC_DEFINEs VARNAME to the expansion of the DIR
dnl variable, taking care of fixing up
Guido,
it appears that something has been going fundamentally wrong. So let's
take a step back and start over.
All personal matters aside, we both aim for the same goal: We want to
provide an useful service to the software development community. I am
sure that our pointless discussion has annoyed
Guido Draheim writes:
>> (5) We leave everything as it is, and the GNU archive starts
>> downloading the contents from the SourceForge archive as well. (I
>> list this option for the sake of completeness. I do not want to
>> include submissions into the GNU archive unless they come from the
>
Braden McDaniel writes:
> It's ridiculous for two completely separate ac-archive projects to
> exist.
I agree with you.
The following possible solutions come to my mind:
(1) The SourceForge "branch" is shut down entirely. The macros it
does have exclusively go into the GNU archive, wher
Alexandre Duret-Lutz writes:
> My impression is that the macro submitter now has to maintain two files:
> - the m4 file, that should be readable by autoconf, and that
> he/she is using in his project
> - and a separate XML file, that duplicates the code
The XML file can reference the
Guido Draheim writes:
> I hand out cvs access to the sfnet branch quite freely [...].
What, according to
http://sourceforge.net/project/memberlist.php?group_id=32081
accounts for the two developers:
Bruce Korb
Guido Draheim
The ones, who's macros the GNU archive does not have.
I quoted, among others, the following CVS IDs:
> $Id: ac_config_libconfig_in.m4,v 1.2 2002/04/19 12:03:00 simons Exp $
> $Id: ac_config_libconfig_in.m4,v 1.4 2002/09/12 22:11:52 guidod Exp $
> $Id: ac_config_pkgconfig_in.m4,v 1.2 2002/05/06 11:47:30 simons Exp $
> $Id: ac_conf
I am sorry to disturb your emotional "we should all be friends"-speech
with _facts_ once more. You wrote:
> I did use the link to the sfnet [archive when answering questions,]
> since I knew it was up to date while it became a common case the
> the gnu part was possibly a few weeks thereafter.
Guido Draheim writes:
> [binding synopsis more closely to description]
Technically, the tag could contain legal XHTML 1.0.
element. I intentionally limited the number of valid tags to make the
format less confusing, but basically the DTD would allow for complete
XHTML a.k.a. HTML 4.01 to be use
Let me summarize the statements you made in your e-mail:
(1) You cannot commit new versions of macros into the GNU archive
because I revoked your CVS access:
> I would well do so, but you threw me out of cvs access, and
> having a dozen macros send by mail is a tedious task [...
Guido Draheim writes:
> I am not sure however if it is best to use instead of a proper
> list that gets visuallized with as a the list combined with
> between them.
IMHO the only viable alternative would be to use an abstract
description of "macro parameters", which describes semantics. The
Guido Draheim writes:
>> - A short description of the macro (summary) is visible on the
>> index page.
> I did try that lately too - but dumped it as it did clutter the
> index page with information not really helpful.
There is no need to force the summary onto the index page. It is
absolute
tails, let me
show you what a macro submission in the NEW format looks like:
|
| http://gnu.org/software/ac-archive/dtd/acmacro1-xml.dtd";>
|
|
| PETI_ENABLE_DYNAMIC_LINK
|
| PETI_ENABLE_DYNAMIC_LINK
|
| $Id: peti_enable_dynamic_link.xml,v 1.2 2003/01/15 23:48:53 simons Exp
|$
Bruce Korb writes:
> The main issue I see with autoconf macros is that they appear
> jumbled, which intimidates, and there are nasty little twists that
> catch the unwary. [...] Adding to that with SGML/DTD overhead adds
> just that much more clutter. Keep It Simple!
I hope you don't misunde
Alexandre Duret-Lutz writes:
Peter> Furthermore, I wrote a formatting engine that will parse the SGML file
Peter> to (a) extract the macro as raw m4 file
> I whish you could do the converse: keep the raw m4 file as the
> source and extract whatever you want from this.
Good point. I see two
files.
| dnl
| dnl @version $Id: peti_path_sendmail.m4,v 1.4 2000/12/31 10:18:09 simons Exp $
| dnl @author Peter Simons <[EMAIL PROTECTED]>
| dnl
| AC_DEFUN([PETI_PATH_SENDMAIL], [
| peti_path_backup=$PATH
| PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/lib:/usr/libexec:/usr/local/bin
| PATH=$PATH
Russ Allbery writes:
> You also need _LARGEFILE_SOURCE.
I added that define and recompiled, but unfortunately g++ fails with
the same error message when _LARGEFILE_SOURCE was not defined, so the
define doesn't seem to make any difference.
-peter
Albert Chin writes:
> So, if your program uses open(2) and you link, you get an
> unresolved reference to the symbol open?
No, the header files doesn't even define the open(2) prototype
anymore, thus compilation fails:
| g++ -DBYTE_ORDER=BIG_ENDIAN -Du_int32_t=uint32_t -Ilibgetopt \
| -
I have the following problem: My code depends on BYTE_ORDER being
defined to either LITTLE_ENDIAN or BIG_ENDIAN. So I use the
AC_C_BIGENDIAN macro to deterimine the endianess, but unfortunately,
the macro does not define the names as I would need them. No big deal,
I simply use the following code
Hi,
I recently added AC_SYS_LARGEFILE macro to my configure scripts, but I
encountered an interesting problem on Solaris 8: The configure script
adds the define "_FILE_OFFSET_BITS=64" to my CPPFLAGS, but once it
does, and colleagues don't define open(2) anymore;
apparently, I have to use open64(
Hi,
I recently upgraded to Autoconf version 2.52 and noticed the following
problem on FreeBSD 4.3:
| configure: creating ./config.status
| config.status: creating xds.h
| mv: xds.h: set owner/group (was: 10003/0): Operation not permitted
| config.status: creating xds-config
| mv: xds-config
Hi everybody,
finally, the autoconf archive made it to the official gnu.org web
server. It is now available at:
http://www.gnu.org/software/ac-archive/
The old location will re-direct requests to the new URL for a while,
but I'd humbly ask everybody to update the links on their pages to the
Christopher Faylor writes:
> I'm happy to do this [...]
Great! I'll contact you via private e-mail to discuss the details
then. Thanks for the quick reply!
-peter
Hi everybody,
due to a change of jobs, I am losing access to research.cys.de -- the
current home of the autoconf macro archive. I could in fact move the
archive to some other site (http://cryp.to/), but I wonder whether it
wouldn't be smarter to use the oportunity to host the autoconf archive
som
> Thomas E Dickey writes:
> how are you going to enforce it?
> (is there a tool...)
Right now I will just enforce it manually. My converter doesn't parse
the macro contents at the moment and I don't really want to start
adding that feature as I am sure it will not work in 100% of all cases
> Akim Demaille writes:
> dnl is still useful: it documents M4 constructs.
> # is useful: it document Autoconf issues.
I see your point. I think we settle for a compromise and allow both
forms and explicitely mention both forms on the autoconf archive web
site. Then we can let the macro a
> Akim Demaille writes:
> ~ace % m4nostromo 15:18
> define(`count', `I have $# arguments')
> count(a, b, c)dnl Hm, you should be three...
> I have 3 argumentsdnl Hm, you should be three...
> count(a, b, c)# Hm, you should be three.
> Akim Demaille writes:
> I'm sorry, but your argument makes no sense to me. I suppose it
> also means I should not use the pattern /* in sh because it might
> be a C comment? Or the converse?
The difference is that when I write "dnl some text" in an m4 file, it
is ignored as a comment no
Dear Autoconf users,
this mail is going to the autoconf mailing list for the benefit of all
readers. An additional blind carbon copy has been sent to all authors
of macros contained in the archive that were affected by the change.
It has been recommended to enforce the macro name in all definiti
> Ruslan Shevchenko writes:
> # RSSH_CHECK_SUNPROC_C([ACTION-IF-YES], [ACTION-IF-NOT])
I have added the macro to the autoconf archive a few moments ago;
thanks for the submission. I reformatted it quite a bit to make it
comply with the archive requirements, so you might want to get the
sour
For various reasons I would like to move the autoconf macro archive to
another machine than peti.cys.de, which happens to be my desktop PC.
Currently the archive is available under both the old URL
http://peti.cys.de/autoconf-archive/
and the new one:
http://research.cys.de/autoconf-arc
39 matches
Mail list logo
