d under the Creative Commons CC-BY-SA license in
the patent-free "webm" format (though it's also available via youtube). I used
only FLOSS tools to make the video.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
detects if AC_INIT is missing, or if
any of its parameters are not normalized.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
that AX_CREATE_PKGCONFIG_INFO is the best available approach, since it's the
closest-available to correct that's easy to do.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
fail to do it correctly.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
o write that right now, but hopefully you see what I think
is wrong with the current situation. And maybe I can convince someone else to
write it...!
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
the configure.ac file, and it'll be run at that point.
If they're in a conditional, you should use AS_IF and AS_CASE, not if...fi and
case...esac; the autoconf documentation describes those.
--- David A. Wheeler
___
Autoconf mailing li
ng flags all over the place, during development,
a lot of bugs would simply disappear.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
in the site or system-wide config
files. But since these capabilities aren't baked into autoconf, they are
unlikely to be in the system-wide config files either.
Paul Eggert:
> Abstractly, I think Autoconf machinery to support security
> checking is a good idea, bu
S
git add m4/NOTES
Then add to Makefile.am (to force redistribution):
EXTRA_DIST = m4/NOTES
A little explanation on *why* here:
http://www.dwheeler.com/autotools/
Sorry if this was obvious and you've already done that.
--- David A. Wheeler
find looking at some examples helpful.
And to point out the obvious: Don't try to do everything at once. Break things
down, and get one thing working at a time. The autotools are not *nearly* as
complicated to understand and use as they used to be (thanks guys!).
--- David A. Wheeler
___
d
why that's not automatic. But if it's not enabled by default, autoconf
should come with a macro to detect and enable hardening options
for common compilers/linkers. If it's easy to turn on, more people will do it.
That way, programs would be harder to a
PROG_CC" would detect warning levels, set some default,
and then configure.ac could do:
AC_PROG_CC_WARNINGS([low]) # off, low, medium, high; default medium
and in gcc "medium" might map to "-Wall".
Does that sound reasonable?
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
> David A. Wheeler wrote:
> > AC_PROG_CC_WARNINGS([low]) # off, low, medium, high; default medium
> > and in gcc "medium" might map to "-Wall".
On Tue, 29 Oct 2013 21:00:05 -0700, Paul Eggert wrote:
> I'm afraid in practice things are not quite that
riginal
developers.
If there are a lot of warnings, that's a hint to the production builder that he
might
want to check further. Maybe they're all legit... or maybe the original
developer keeps
making bone-headed mistakes. Warnings tell people that something
might not be okay, and wh
g.:
# The installchecks won't work in a "make distcheck", because
# they won't be installed in the final location used by the tools.
if IS_MAKE_DISTCHECK
installcheck-local:
echo "Running 'make distcheck'; local installchecks disabled."
else !IS_MAKE_DISTCHECK
installcheck-local: installcheck-clisp installcheck-guile
endif !IS_MAKE_DISTCHECK
Yes, it's awkward, but it works. Then "make distcheck" works as intended.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
at the *name* is, as long as
it's clear.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ir particular project in a relatively compiler-agnostic way).
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
;fixed"... and they're way more
likely to be fixed or documented if the users can easily see them.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ortant that warning flags be on by *default*,
as I've posted earlier. If it's only an option, then in many cases developers
and users
will fail to see the warnings that often hint at serious problems
(as sadly happens now).
--- David A. Wheeler
___
'-Wall'". That should make it much easier to
portably add option flags when a particular flag sequence has different
meanings between compilers. That's what the code for computing the default
warning flags does anyway; this change would make that functionality easily
accessible to users.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
k here:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Portable-Shell.html
and especially:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
y're building has a
host of likely problems.
Developers typically work primarily on stuff that's visible to
builders and true end-users. By making such problems more visible
to builders by default, they're more likely to get fixed.
--- David A. Wheeler
___
David A. Wheeler wrote:
> > I*AM* advocating a*basic* warning level by default.
> > I interpret that on gcc to be "-Wall" or some variant.
Paul Eggert:
> -Wall generates too many false positives in practice. Perhaps some
> variant would be better, but we'd ha
quot;) is clear
enough.
Since they are *not* gcc-specific, the name "gcc" should not be in the name of
the configure flag.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
This does not help you right now, but Dale Visser posted a patch to autoconf a
few months ago that would solve your problem correctly. His patch adds the
ability to check if a compiler supports a particular flag. My hope is that this
ability will soon be added to autoconf. Clearly some people wa
Another tutorial you might find useful is here:
http://www.dwheeler.com/autotools/
It is only an introduction, but I think it helps people get started.
I think the goat book is too old to be useful as a tutorial.
--- David A.Wheeler
___
Autoconf mailin
icular functions or
.h files. Dale Visser's recent patch makes it easy to probe if a specific
compiler flag is accepted (if accepted, I hope it will be).
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ot;important" bug fixes, so
comparing version numbers doesn't always work anyway!
However, compiler flags are special. Unknown compiler flags can be tricky to
detect. E.G.:
gcc -o hello -IS_DUCK hello.c
will silently work, and report no error code.
Portably adding compiler flags is o
when working with the U.S. government,
and in many other cases as well. Billions of dollars are spent on open source
software today.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
ll enables extensions, even though the test is false.
I'm trying to conditionally use extensions like this:
AS_IF([test "$enable_all_system_extensions" = "yes"],
[AC_USE_SYSTEM_EXTENSIONS])
Am I going about this the wrong way?
Suggest
*test* the alternatives.
Thus, I want to be able to easily *disable*
extensions & then see if the code compiles/links/runs correctly.
My intent was to add a simple configure flag to disable extensions, to enable
some basic testing in those cases.
--- David A. Wheeler
__
eople (including me!) want to counter
attacks against development and build environments, e.g.:
https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html
http://www.dwheeler.com/trusting-trust
A reminder might encourage someone to harden their system before
C_CHECK_PROG,
and the result would be much better automation on many systems.
This is a slightly tricky problem; comments welcome. It'd be nice to see
a simple and relatively clean solution to the problem. I think "use
double-quotes when
pathnames contain spaces" is a plausible answer.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
y if they use Mac OS X or Windows,
and not something they can change.
They can do workarounds with symlinks, etc., to try to *hide* the reality, but
since autoconf is supposed to do things *automatically*, that means that
autoconf fails to do the one job it's supposed to do: automatic conf
kefile would have the quoting scheme, while a #include file would
not).
But the fundamental problem is that there's no way to distinguish the
different uses of spaces; once there's an input and storage convention,
you can then decide how to best output them.
--- David A. Wheeler
__
David A. Wheeler wrote:
> > Sure, but this minor variation WOULD work in a makefile, and it's an easy
> > fix:
> > $(MAKE) SBCL='$(SBCL)'
On Wed, 31 Dec 2014 11:31:58 -0800, Paul Eggert wrote:
> That won't work if SBCL contains single quotes, another c
Paul Eggert:
>Sure. So create a symlink to that, e.g.,
> ln -s '/cygdrive/c/Program Files/Steel Bank Common Lisp/1.2.6/sbc' /tmp/xyz
> Then configure with the equivalent of SBCL=/tmp/xyz.
> Obviously the idea needs some elaboration (e.g., if the file name is needed
> at
runtime) but it would w
;than "Re: Contents of Autoconf digest..."
>
>
>Today's Topics:
>
> 1. Re: Mangled argument vector choking on spaces? (David A. Wheeler)
> 2. Re: Autoconf Digest, Vol 128, Issue 6 (David A. Wheeler)
> 3. Re: Mangled argument vector choking on spaces? (Fotis
> It is a common problem for Windows users that their default directory
> (equivalent to a home directory) has spaces in it.
In recent versions of Windows the home directory is often C:\Users (and thus
has no spaces). But the typical directory that contains most programs has a
space in its nam
Fotis Georgatos :
> As regards $subject, this so-called STRING_ENCODING_CHARMAP may be relevant:
https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/tools/filetools.py#L59
Look around line L1000 for the rational of that design and some pointers.
> Basically, ` ` becomes `_space_`
>While paths with spaces in them may be a fact of reality, they are
>non-portable according to POSIX. It is going to be an uphill battle if
>you want to submit patches to make autoconf automatically handle file
>names with spaces, as there is nothing portable about them.
POSIX does not forbid
>While paths with spaces in them may be a fact of reality, they are
>non-portable according to POSIX. It is going to be an uphill battle if
>you want to submit patches to make autoconf automatically handle file
>names with spaces, as there is nothing portable about them.
I just thought of an a
On Sat, 03 Jan 2015 15:37:14 -0800, Paul Eggert wrote:
> David A. Wheeler wrote:
> > E.g. when using AC_CHECK_PROG to search for "sbcl", the generated makefile
> > would say:
> > SBCL = sbcl
>
> That's easy to do without changing Autoconf. Put this
On January 19, 2019 4:44:59 PM EST, Andrew Pennebaker
wrote:
>I wonder if we could speed up builds by remembering the compiler
>features
>that autoconf checks.
It is certainly possible to cache the results. The challenge is in ensuring
that the test is exactly the same. For example, different v
l syntax, it could simply check only certain arguments of
certain macros to see if they meet certain rules.
A linter only needs to focus on detecting *common* mistakes and/or enforce a
style. Hopefully the style rules themselves exist to help avoid common
mistakes. As long as you only try to do that, the inability to handle
everything is just fine.
--- David A. Wheeler
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Here's a list of some style recommendations I made for autotools use:
https://dwheeler.com/autotools/#style
I think a number of them could be implemented by a linter.
You could also warn about a missing AC_INIT and AC_OUTPUT,
although I suspect such problems are rare in practice.
--- Da
> David A. Wheeler (2019/10/07 12:29 -0400):
> > Here's a list of some style recommendations I made for autotools use:
> > https://dwheeler.com/autotools/#style
> > I think a number of them could be implemented by a linter.
> > You could also warn about
“2.70” is before “2.8”. When there are 3 numbers, the
version number
Is unambiguously *not* a real number & the confusion mostly disappears.
Also, most programs of autoconf’s size have switched to semantic versioning
(SemVer),
where 3 numbers are required. Trying to retain the old version numbering
convention
Is a hindrance, not a help.
--- David A. Wheeler
t would however be a long-term goal, not
something done quickly.
--- David A. Wheeler
ity, and occasionally copy from each
other.
So trying to detect “do this if GCC” is generally wrong; clang may have
that interface & functionality
when someone compiles the code.
--- David A. Wheeler
ty, and occasionally copy from each other.
So trying to detect “do this if GCC” is generally wrong; clang may have that
interface & functionality
when someone compiles the code.
--- David A. Wheeler
-exclusively.
This seems like the right approach: First find a useful shell with $(...), then
use that shell.
This localized the pain to the “find a shell” bootstrap.
I suspect many program-specific scripts use $(...),
so this will actually *increase* the portability of the final result.
--- David A. Wheeler
ct me if you wish to participate.
It’s not exactly what you asked for, but may I recommend
my short 3-part series of Youtube videos on the autotools?
Start here:
https://www.youtube.com/watch?v=4q_inV9M_us
<https://www.youtube.com/watch?v=4q_inV9M_us>
--- David A. Wheeler
gt; $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS)
> $(AM_CFLAGS) $(CFLAGS)
> ...
> Usage of CPPFLAGS before CFLAGS looks logical for me, I think autoconf should
> be fixed.
I don't have any special standing here, but I agree, that seems logical to me
too.
--- David A. Wheeler
r back. I'm undecided about this.
Another option is to quietly try to create the TMPDIR directory like "mkdir -p".
The user specifically requested it, so it makes sense to try to honor it.
--- David A. Wheeler
to be errors by default. Details/context below.
--- David A. Wheeler
=== Details ===
The Open Source Security Foundation (OpenSSF) has developed
"Compiler Options Hardening Guide for C and C++"
<https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-fo
56 matches
Mail list logo
