Re: Core-utils 7.2; building only 'su'

>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 >| spec

Re: Core-utils 7.2; building only 'su'

>packages where DESTDIR doesn't work properly. But automake >already does such a good job at providing DESTDIR support >(especially if the user remembered to run 'make distcheck'), >that I think it would be nice if using AM_INIT_AUTOMAKE did >make the ./configure

Re: Core-utils 7.2; building only 'su'

> 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

Re: Core-utils 7.2; building only 'su'

>>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

Re: Core-utils 7.2; building only 'su'

> 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 mi

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

+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 confi

Re: improve INSTALL contents

>+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 y

Re: improve INSTALL contents (was: Core-utils 7.2; building only 'su')

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

Re: improve INSTALL contents

>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 >

Re: improve INSTALL contents

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

Re: improve INSTALL contents

>> 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

Re: improve INSTALL contents

can you please also read, and follow ? 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 a

Re: improve INSTALL contents

I believe his point is that this thread seems disproportionately long (and cross-posted too widely) for the small potential benefit, if ever something comes of it. Ralf doesn't need to read, or even respond to the thread if that is the case. I like the blurb Eric suggested, Most pack

mention --{disable,enable}-silent-rules

- It would be good if the silent-rules API (--{disable,enable}-silent-rules, and V=0, V=1) were mentioned somewhere. Totally agree. I don't have the source code for autoconf here so no patch, but one could mention setting V=0/V=1 in config.site if one wishes to permanently flip the v

Re: Choosing not to install documentation

Under certain circumstances, users don't want to install *any* documentation files from my project. I'm not sure what those conditions are, or why it is a good idea to make live hard for users; but isn't it easier to just do `rm -rf /usr/share/doc /usr/share/man' after `make install'?

Re: Choosing not to install documentation

> but isn't it easier to just do `rm -rf /usr/share/doc > /usr/share/man' after `make install'? And thereby remove installed documentation for hundreds of other, unrelated packages? I was guessing that the OP had a very constraied system where you would not need it, on any general pur

Re: Choosing not to install documentation

>> but isn't it easier to just do `rm -rf >> /usr/share/doc /usr/share/man' after `make install'? Easier than having "--disable-installdocs" or the equivalent? I don't personally think so. You need to add --disable-installdocs to _all_ packages that use autoconf, this is non-trivial.

Re: Choosing not to install documentation

But at any rate, I think I've found a solution that works for me and certainly don't intend to ask GNU to rework autotools for my sole benefit? :-) Thanks, all! Eric suggest the truly right fix though. :-) ___ Autoconf mailing list Autoconf@g

Re: 'set +o' or '. /dev/fd/0' or?...

Hi autoguys, I am piping the output of a script to the shell, and using COMMAND | sh would not respect the -e/-x settings of the outer shell. I have thought of two replacements: { set +o; COMMAND; } | sh COMMAND | . /dev/fd/0 The second looks nicer, but it's

Re: What IDEs support autoconf-based projects ?

If I want to work on the GNU Hello project, which can be downloaded at http://ftp.gnu.org/gnu/hello/hello-2.4.tar.gz, what IDEs can I use to import the project and export it as deployable project( configure->make) after some dependency and code changes? A normal text editor. Automake,

Re: What IDEs support autoconf-based projects ?

Would it be possible to move this thread elsewhere? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Adding an external project to autoconf

Please see `(autoconf) Subdirectories' in the manual. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: Adding an external project to autoconf

The sub-projects must contain all generated files. That is, autoreconf will not traverse anything listed in AC_CONFIG_SUBDIRS (which it probobly should though). Do those directories contain Makefile.in, configure, etc? ___ Autoconf mailing list Autoco

Re: project in multiply directories

There is an article called "recursive make considered harmful". According to it, you should have just one Makefile.am in top level with all the rules (all libs etc). By this, make can show its strengths best. Often, a Makefile.am "per directory" seems to be used, but for a new projec

Re: project in multiply directories

> There is an article called "recursive make considered harmful". > According to it, you should have just one Makefile.am in top > level with all the rules (all libs etc). By this, make can show > its strengths best. Often, a Makefile.am "per directory" seems > to be used,

Re: Process output of a simple command

Why not print a message if that bug is found instead of depending on the architecture which surley will backfire, since you could be running GNU/Linux or anything on such a machine. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman

Re: Process output of a simple command

> Why not print a message if that bug is found instead of depending on > the architecture which surley will backfire, since you could be > running GNU/Linux or anything on such a machine. It would be somewhat difficult to detect the bug, as it is by its very nature random. In fact,

Re: pkg-config wisdom

> I imagine that pkg-config has not been integrated into Autoconf > because it does not fit well into the Autoconf philosophy. I use pkg-config quite heavily in one of my projects, I'm just wondering is there a more "autoconf" way of performing the same task as I constantly run into

Re: pkg-config wisdom

And please, don't say about "Linux has interlibrary dependency for shared libraries". First at all, not all libraries are shared (even under Linux). Second, Linux is not only one flavor of Unix. Linux is a kernel, the operating system you are refering to is called GNU or in conjuction w

Re: pkg-config wisdom

> pkg-config tries to solve an important problem, but it does so in the > wrong way. pkg-config checks for an exact library name, PKG_CHECK_MODULES does not check for a library name at all, but for the name of the .pc file. This gives the administrator one extra level of indirect

Re: pkg-config wisdom

pkg-config is broken because it checks for the existance of libraries, and not for the features that are required for the program to run. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

Re: pkg-config wisdom

> pkg-config is broken because it checks for the existance of > libraries, and not for the features that are required for the > program to run. It does not even check for the existence of libraries. It checks for the existence of a .pc file and assumes that the user (or administr

Re: pkglibdir vs. lib64

I'm developping plugins that I wish install in /usr/lib/nautilus-actions or /usr/lib64/nautilus-actions depending on the platform. But pkglibdir is resolved to /usr/lib/nautilus-actions both in 32 and 64 bits environments (fedora 11, autoconf 2.63). That is as intended, system libr

Re: pkglibdir vs. lib64

This will fix my own problem, and it's already great ;-) As a package maintainer, I wondered how to make more easy the packager work - I'll just drop a comment in Makefile.am... A better place for such comments is the README file. As far as package maintainers go, they should install hos

Re: pkglibdir vs. lib64

> As a package maintainer, I wondered how to make more easy the > packager work - I'll just drop a comment in Makefile.am... a package maintainer is already aware of these issues as it'll apply to a vast number of packages to the relevant distros. adding comments to your specific p

Re: pkglibdir vs. lib64

> Such a comment is also more suitable in the README, since a > packager will not read the Makefile.am. A diligent distro package maintainer certainly reads the Makefile.am, and also reviews the full diff between upstream releases. Very few packages do this, and it is immensly unfe

Re: Server Adjustments

I understand.,, but what happens about /etc/init.d shell scripts (I mean the ones which start, stop & restart servers) ? Would be possible to get more info about the way of manage them ? That is very operating system dependant, gNewSense does it one way, Fedora another, Ubuntu yet anothe

Re: Server Adjustments

But right now, I've a little problem because my server has a configuration file. I thought that the best place to place it would be the /etc folder... It seems that it's precisely the default value of $(sysconfigdir), but I don't know if it's possible to my server (my programm) knows

Re: AC_PROG_LD manual?

I have a configure.ac here which uses AC_PROG_LD, but I don't know about the purpose of this macro. Unfortunately I do not find and any doc about it. AC_PROG_LD is a old macro from libtool (though more aptly named), you should use LT_PATH_LD instead. (libtool) Autoconf macros: -- Macro:

Re: AC_PROG_CC_C99 and AC_OPENMP

It seems a shame that the test for OpenMP does not allow the user to specify a minimum version that the implementation needs to satisfy before it will be used. OpenMP has been around for quite a while now and there are quite a few versions. Testing for a version number is always the w

Re: Autotools book published

Is this book published under a free documentation license? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf

autocache

Ralf asked me to send a small blurb, during FSCONS 2011 there was discussion about how to make ./configure run a faster when hacking. The simple solution is to generate a config.cache that one uses, and reuses; so in the end I wrote autocache which simply runs as many autoconf/automake/gnulib check

Re: autocache

I suggest to not put config.cache in the source tree, which also fits the nodist_ description you used in Makefile.am. If you don't mind, I'll push the fix as below. Please do, that was the idea with the fully writable tree. Then, how did you come up with the list of gnulib modules i

CONFIG_SITE in srcdir

What does everyone think of making configure look for CONFIG_SITE in srcdir instead of just in $prefix/share/config.site and $prefix/etc/config.site? 2002-12-31 Alfred M. Szmidt <[EMAIL PROTECTED]> * lib/autoconf/general.m4 (AC_SITE_LOAD): Search for CONFIG_SITE in