gmane.comp.sysutils.autoconf.general

Re: config.status: error: cannot find input file: `po/Makefile.in.in'

Kip Warner — 2013-05-19T09:53:50

Hey Gavin. I already went through the manual, but I'm guessing I must
have missed something. Indeed, I had. I just found the problem was in a
side effect gettextize left in configure.ac in AC_CONFIG_FILES which
pointed to the dead po/. I missed that the first time I went through it,
but thanks for bringing that to my attention.

But back to the manual, I see there's a lot of things that need to be
modified all over the place in an autotooled project to use gettext, but
one thing I wasn't sure of was how much of it still needs to be done
manually after gettextize has managed to gettext'ify the project?

Re: config.status: error: cannot find input file: `po/Makefile.in.in'

Gavin Smith — 2013-05-19T09:38:51

Do you still have a reference to "po" in configure.ac? Sections 13.4
and 13.4.5 in the gettext manual look relevant to your problem.

config.status: error: cannot find input file: `po/Makefile.in.in'

Kip Warner — 2013-05-19T08:57:53

Hey list,

I have my message catalogues in a directory in my project other than in
the usual po/. I ran gettextize --po-dir=folder. I also updated
Makevars's subdir to point to the new directory. The SUBDIRS variable in
my Makefile.am also points to the right location.

However, the error I am receiving when I run ./configure is the
following, despite po/ not existing:

        config.status: error: cannot find input file:
        `po/Makefile.in.in'

Any help appreciated.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Henrique de Moraes Holschuh — 2013-05-18T12:42:59

IME, it is much better when any override mechanism make use of environment
variables.  These are very easy to set per-build, per-user and system-wide,
unlike system-wide files and even per-project files.

It would be enough for the environment variables, when present, set the name
of the override files, and default to local config.{sub,guess}.override or
whatever when the variables are not set.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Paul Wise — 2013-05-18T11:45:54


My original patch didn't allow overrides, here is an updated one.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Warren Young — 2013-05-17T20:43:50

You're starting from an assumption that autotools are installed on all 
systems where you would want to build an autoconfiscated package.

For example, on Cygwin and FreeBSD, a C compiler is optional, and 
installing it doesn't drag in the autotools.

All you're supposed to need to build an autoconfiscated package are 
sh(1), make(1), and the compiler for whatever language the package's 
source code is in.

I think you have the seed of a good idea here, though.

What if configure behaves just like it currently does unless it sees 
that config.{guess,sub}[.override] aren't present at all?  It can then 
go looking for default versions in the usual system locations.

OS package creation tools could offer a per-package flag in the 
package's configuration (.spec, .ebuild, .cygport, debian/...) that 
tells it it is safe to remove shipped config.{guess,sub} files from the 
tarball when building the source package, and that it should autoreconf 
the package to get a configure script and Makefile.in that's aware of

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Henrique de Moraes Holschuh — 2013-05-17T19:05:17

Yes.  It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Warren Young — 2013-05-16T19:28:39

So, because Gentoo has N text editors in the repo, the N+1th text editor 
must port to Gentoo without problems?

You're committing a logical fallacy here, hasty generalization.  "All 
things in class A have property B, hence all things have property B."

The packages in Gentoo are ipso facto packages that *can* port to 
Gentoo.  You can't infer from that that all packages port to Gentoo 
without requiring adjustment.


Why?

You propose changing the way autoconf works based on a sampling of 
projects using it.  A large sampling to be sure, but probably not 
anywhere near a majority of those using autotools.

You *think* you know how your change will affect all those projects you 
don't get to see, but you do not actually know, because you're working 
from a biased sample.  (Biased because it's an inherently anti-closed 
source, anti-commercial[1] sample.)

This seems like it might be a relevant consideration to me.


Fallen tree fallacy.

When the entry in the bug tracker (in a forest of bug trackers) is no

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Paul Wise — 2013-05-15T23:23:34

Yes, it is a very common hack in all of the distros.
It would be nice if that wasn't necessary in the first place though.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Wookey — 2013-05-15T21:28:15

+++ Thomas Petazzoni [2013-05-15 16:30 +0200]:

Same story in OpenEmbedded.

Given the widespread positive experience with this process, at least
in Linux distros, can those who think that defaulting to using
'current' versions is a bad idea produce any examples of genuine
problems large enough to counter the fairly major issue of updating
hundreds of these files for new architectures. Perhaps there are
non-linux arches where lots of things would break?

There have been some theoretical or obscure issues brought up so far
in this thread, and some history, but I haven't seen much that looks
like a good enough reason not to default to use current unless
configured not to (which anyone shipping a 'special' config.sub/guess
can use.

Wookey

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Russ Allbery — 2013-05-15T20:34:06


I think this may be one of those historical momentum things.  As INN
maintainer, I used to carry local patches to config.guess and config.sub
to add support for platforms on which my users were trying to build INN
that weren't supported by the current config.guess and config.sub scripts,
usually because the patches had been submitted but they were very slow to
release a new version.  This problem went away completely some time back,
with a new and far faster and more responsive process for maintaining
those scripts, and now I just use the most recent released versions for
all packages.  Some projects may still be carrying unnecessary hacks
because they started carrying them back in those days and have never gone
back and revisited.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Mike Frysinger — 2013-05-15T20:27:56

... which is what this sub thread was focusing on, with the only slightly 
bigger picture being distro packaging behavior.  no, not *all* autotool based 
packages are in Gentoo, but we've got pretty good coverage for anything 
passably relevant (and then some).


then they're irrelevant to this sub thread.


obviously that's possible, but i'm fairly certain it's unlikely.  when things 
break w/Gentoo, our devs/users tend to file bugs.

even then, writing your own config.sub is not something to be taken lightly.  
the amount of blood/sweat/tears that have gone into maintaining that database 
dwarfs whatever tiny project random person is working on.  and even even then, 
the number of people who even understand htf autotools work let alone a tiny 
internal nuance like config.sub is fairly (if not extremely) esoteric.

if Gentoo blowing away your rinky dinky config.sub hack breaks your project, 
then take it as a sign that You're Doing It Wrong :).
-mike
_______________________________________________
Autoconf

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Warren Young — 2013-05-15T19:25:31

It's irrelevant *for* *Gentoo*.  Not all autoconfiscated source trees 
are in Gentoo.

I wouldn't be surprised if there were an iceberg effect here: it could 
well be that ~90% of all source trees using the autotools aren't even 
publicly visible, much less incorporated into the major Linux distros.

There's some self-selection bias going on here, too.  Software that 
fails to build in the Gentoo build system obviously won't get adopted 
into Gentoo, if no one bothers to try and fix the breakage.

For what it's worth, I'm not entirely against your position.  I do a bit 
of packaging work for Cygwin, and we've got the same core problem over 
there, too, particularly with the nascent Cygwin 64 effort.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Russ Allbery — 2013-05-15T18:20:13



Debian is moving in that direction as well.  We have two different package
helper tools that do this in different ways.  As always with Debian,
though, we're not very centralized about practices, so it takes a while to
get this deployed consistently across the whole archive.

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Mike Frysinger — 2013-05-15T17:20:15

i understand the point you're making.  however, ~10 years of building from 
source in Gentoo and doing this for every single build has shown that in 
practice, it's irrelevant.  we've found exactly one package where this made a 
slight difference (gmp), and even then it was a matter of selecting optional 
optimizations that we can control via other routes.
-mike
_______________________________________________
Autoconf mailing list
Autoconf< at >gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Ralf Corsepius — 2013-05-15T16:26:46

Well, config.sub has allways been amongst those files the autotools 
supposed not to be generated.

That said, if you replace them by brute-force, you are breaking the UI 
of the autotools - Read: an utterly bad idea. RH/Fedora has done this 
for a very long time and has given up doing so for several years, and 
now is relying on packagers explicitly replacing them (autoreconf -f 
rsp. by patching).

A better approach would be to only replace them, if they you are sure, 
they are unmodified.

<comments non-disclosed/>

Ralf

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Mike Frysinger — 2013-05-15T16:13:22

i take the stance that if you haven't merged your code into the GNU config 
project, then you deserve to break.  or at least, you're too bleeding edge to 
be merged into mainline Gentoo (which, honestly, is saying something).  i keep 
the snapshots in Gentoo up to date every few months, or someone asks for it 
sooner (as they just got a change merged), so there's very little to no delay 
syncing there.

and counter point: if someone wants to use e.g. Gentoo to develop things 
early, they can also tweak the host system's gnuconfig package and then *all* 
the Gentoo ebuilds now build correctly for your target :).
-mike
_______________________________________________
Autoconf mailing list
Autoconf< at >gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Thomas Petazzoni — 2013-05-15T14:30:36

Hello,

On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote:


FWIW, we do the same thing in Buildroot (a tool that builds embedded
Linux systems from source, through cross-compilation). Never had any
problem doing so.

Best regards,

Thomas

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Ralf Corsepius — 2013-05-15T13:54:08

Well, I can't imagine a case affecting config.guess, but constructing 
cases affecting config.sub is pretty simple.

Classical use-case is developing on cross-built packages, which require 
a new host/target-tuple and therefore ship a customized/modified config.sub.

Those cases are rare in publicly available/released packages, but they 
are not uncommon in the toolchain/OS developer's community. Think about 
working on "cfin-MikeOS" toolchain in binutils/gcc/gdb or adding support 
for it to other auto*tools-based package ;)

At least for RTEMS, we had once carried such a customized config.sub for 
a short period time.

Ralf

Re: [RFC] getting rid of the config.guess/sub problem whenbootstrapping new ports/systems

Mike Frysinger — 2013-05-15T03:53:44

yes, Gentoo fixed this for every package in our tree like 9 years ago (we added 
a common function like 11 years ago that ebuilds could call manually, but we 
found that didn't scale).  when you run a standard autoconf script, we 
automatically search for files named "config.sub" and "config.guess" and replace 
them with the up-to-date host copy.  no checking or anything :).  in 
hindsight, that seems like a bad idea, but in practice, i think we have yet to 
find a package that this doesn't actually work.

and behold, no one has ever complained about config.sub not recognizing their 
mips or sparc or x86_64 or aarch64 system ever again.


if Gentoo is the only one that uses /usr/share/gnuconfig/ and every one else 
picked /usr/share/misc/, then i'll just move Gentoo.  don't bother listing it 
in your patch.  even then, many of the other paths (like internal 
automake/libtool) will work fine on Gentoo.

we picked .../gnuconfig/ as it installs more than one file and FHS generally 
recommends that packages w/m

Re: configure complexity

Mona Pinjani — 2013-05-09T19:44:59

Hi Bruce,

Thanks for the quick reply. There is no install-sh in $HOME. Here is the
output you requested
-bash-4.1$ build-aux/config.guess
x86_64-unknown-linux-gnu
-bash-4.1$ grep 'Generated by GNU Autoconf' configure
# Generated by GNU Autoconf 2.69 for Complexity 1.0.


Mona


On 5/9/13 2:30 PM, "Bruce Korb" <bkorb< at >gnu.org> wrote: