Re: Re: patch: generate *.gmo files to the source directory

Jonas Fonseca <[email protected]>
Newsgroups gmane.comp.web.links
Message-ID <[email protected]>
Kalle Olavi Niemitalo <[email protected]> wrote Tue, Dec 06, 2005:
> Jonas Fonseca <[email protected]> writes:
> 
> > However, after running cg-export we run ./autogen.sh,
> > ./configure and for the HEAD branch 'make -C po' so that people without
> > the autotools and gettext tools installed can use the tarballs.
> 
> I am surprised you tar up an already configured tree, as INSTALL
> tells the user to run ./configure.

Well, that is mostly in order to populate doc/ with some nice HTML docs.

> >> Anyway, po/*.gmo wouldn't be the only generated files in the
> >> source tree.  Specifically, autogen.sh places several files
> >> there: acinclude.m4, aclocal.m4, config.h.in, and configure.
> >> If storing po/*.gmo in the source tree would cause you trouble,
> >> how do you cope with these?
> >
> > They are kind of different, IMO, since those generated files can be
> > shared across several builds, no?
> 
> po/*.gmo can also be shared across builds, if po/*.po are the
> same in each build.  If the po/*.gmo files depended on the user's
> compilation environment or configuration options, there'd be
> no point in adding them in elinks-*.tar.gz.  (IIRC, there are
> big-endian and little-endian variants of the GNU MO format, but
> the GNU Gettext library can recognize and convert them on the fly.)

You obviously feel very strong about this, and I don't really, although
I really like the idea of putting 'compiled' stuff in the build dir.
Also I think it makes sense to have all generated by ./autogen.sh in the
source dir (the bootstrapping) and everything else (generated by
./configure and make) in the build dir. Does it really make that big a
difference?

-- 
Jonas Fonseca
_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.