Hmmm. Would it be worth changing autoconf to make './configure
--help' state something like the following:
| Some influential environment variables:
| ...
| DESTDIRleave unset during configure; allows installation to
| specify a
I tend to agree that INSTALL should either mention DESTDIR (and
probably also V, which now plays a role with new enough
automake), or at least point to the GNU Coding Standards and the
Automake manual overview of the GNU build system. Does anyone
want to beat me to a patch?
Hmmm. Would it be worth changing autoconf to make './configure
--help' state something like the following:
| Some influential environment variables:
| ...
| DESTDIRleave unset during configure; allows installation to
So for maximum portability you should support this in your
package, too. BTW, why do you state that overriding just $prefix
would be almost always wrong?
In the w32 arena, overriding $prefix at `make install' time is
unilaterally *correct*. Why can your staging area not mirror
+Depending on the package, the default directory layout chosen during
+...@command{configure} can be altered during subsequent execution of
+...@command{make}.
A `make install FOO=VAL' should never alter anything in the build
directory. The problem is if you pass --bindir=/foo to
How about this? I took into account Ralf's comments as well.
In addition, if you use an unusual directory layout you can give
options like @option{--bind...@var{dir}} to specify different
values for particular kinds of files. Run @samp{configure --help}
for a list of the directories
What about packages that don't support arbitrary prefix override
(all those using current libtool), or packages or systems that
don't support DESTDIR installs? This wording creates problems
for them.
Indeed - I want to be very clear in INSTALL that there are some
In addition, if you use an unusual directory layout you can give
options like @option{--bind...@var{dir}} to specify different
values for particular kinds of files. Run @samp{configure --help}
for a list of the directories you can set and what kinds of files
go
Indeed - I want to be very clear in INSTALL that there are some
basics that pretty much any client of this file provide (make, make
install), and some options that nice packages provide but which may
fail if someone borrowed this file but does follow everything
checked by automake's
can you please also read, and follow
http://lists.gnu.org/archive/html/autoconf/2009-05/msg00058.html?
I'm sure you must have missed it because I failed to spam it to
three mailing lists. But your repetitions are just as boring as
those from everyone else. And get bug-coreutils
Index: automake/m4/init.m4
===
--- automake.orig/m4/init.m4
+++ automake/m4/init.m4
@@ -107,6 +107,7 @@ dnl is hooked onto _AC_COMPILER_EXEEXT e
AC_CONFIG_COMMANDS_PRE(dnl
[m4_provide_if([_AM_COMPILER_EXEEXT],
You didn't answer why you need this switch, only that you want it.
I basicall want to do in a Makefile.am
ifdef automake version 1.4
AM_LDFLAGS=...
else
LDFLAGS=...
endif
Because am version == 1.4 does not like
some newer automake macros and I am moving a big project over
to am 1.10. I need the 2 versions to coexist for a while
And there are many examples of the opposite where less verbose output
is useful, automake already supports silent compilation. I know that
I have missed errors or warnings beause having had to much output to
read, Joakim, would you like to work on a patch for this? I think it
would be immensly
And there are many examples of the opposite where less verbose
output is useful, automake already supports silent compilation.
I know that
Yes, but automake --silent is a different tool, perhaps it should
learn suppress the install mgs as well as other libtool msgs such
as
I was refering to AM_SILENT_RULES, which supresses `make all'
output; so this is not a very controversial topic, it is already
in automake and used by several projects. Would you like to work
on this feature? The maintainers can't accept a patch that
doesn't exist after
If the file is; /usr/local/include/package/header.h
and source is; #include package/header.h
what goes in configure.ac?
You shouldn't put anything into configure.ac; if you wish to tell your
compiler where to find non-standard headers (i.e. anything the
compiler doesn't search by
CPPFLAGS=-I/usr/local/include ./configure
Bzzt. Please pass variable settings as arguments to configure:
./configure CPPFLAGS=-I/usr/local/include
not as environment variables. It has the advantage that
./config.status --recheck
(which may be triggered from a
However, make install installs unimain into /usr/local/bin
Please refer to the manual, it documents how to do that, and more.
You can try the chapter `(automake) Fine-grained Distribution
Control'.
Have you tried reading `(automake) Autotools Introduction'? It is part
of the automake manual.
If searching is the problem how does the indices not fix the problem?
What about using a info browser to search through the manual?
2010/3/22 Alfred M. Szmidt a...@gnu.org:
If searching is the problem
*Web* searching is the answer, not the problem.
It isn't when you are not connected to a network.
how does the indices not fix the problem?
I rarely find anything useful in the indices other than particular
You say that the manuals are poor and that it is obvious, but I cannot
figure out from your explanation how they are poor. I've looked at a
few manuals, glibc, emacs, coreutils, autoconf, and m4, and all of
them have good indices, are organised cleanly, etc.
Can you mention one or two manuals,
If I call :
$ make
The .info file is built.
If I call :
$ make clean
The .info file is not cleaned.
It is the same thing for pdf, if I call :
$ make pdf
The .pdf file is built.
If I call :
$ make clean
The .pdf file is not cleaned.
Is there a rule which
If I call :
$ make
The .info file is built.
If I call :
$ make clean
The .info file is not cleaned.
It is the same thing for pdf, if I call :
$ make pdf
The .pdf file is built.
If I call :
$ make clean
� �If I call :
� �$ make
� �The .info file is built.
� �If I call :
� �$ make clean
� �The .info file is not cleaned.
� �It is the same thing for pdf, if I call :
� �$ make pdf
� �The .pdf file is built.
� �If I call :
� �$ make clean
�
The reason why users are helpless without debugging symbols is if a
program crashes, all they can look at are the machine registers at the
state of the crash. This is completely useless for figuring out why
the program crashed, or getting help from another hacker to figure out
why it crashed.
- Have them distributed (automake's default). This means that
they will be build in the srcdir, not in the builddir: of
course, this only affects the maintainer, since for a user that
builds the package from a tarball those files should *not* be
rebuilt, hence
* Such an automated release building service is a piece of SaaSS.
CI is not SaaSS, how is it different?
I can
hardly imagine how we at GNU tell people "SaaSS is as bad as, or worse
than, proprietary software" and at the same time advocate the use of
such a service.
Bluntly, I don't think it would help with security. The attacker would
just have to disable or adjust the distcheck target to seemingly pass.
Yeah, it should be noted that the way the backdoor got into the code
was by the _co-maintainer_ -- distcheck or not, would not have
mattered,
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
There is a bit more to it all than just this -- the maintainer wasn't
responsible (Lasse Collin), the
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively trivial attack
I'm thinking that maybe config.h should be generated with a double
inclusion guard
But the general rule is that config.h must always be included
first, no? So there shouldn't ever be a possibility of including
it twice.
Right, which is the case in inetutils in all places where
I'm thinking that maybe config.h should be generated with a double
inclusion guard
But the general rule is that config.h must always be included first, no?
So there shouldn't ever be a possibility of including it twice.
It might be better to have config.h do something
I think that autoconf should have the guard for double inclusion.
Autoconf does not need to provide a double-inclusion guard for
config.h, because those packages that need it can get it through
use of AH_TOP and AH_BOTTOM.
That is not a reason to not include such a guard.
- Have them distributed (automake's default). This means that
they will be build in the srcdir, not in the builddir: of
course, this only affects the maintainer, since for a user that
builds the package from a tarball those files should *not* be
rebuilt, hence
36 matches
Mail list logo
