> (Answering only for Automake, because I've also been confused by
> Akim's last statements about announcements that shouldn't be
> considered official.)
Sorry about this. I was trying to make a difference bw pre-released
on my web site, and really released on GNU site. Maybe that was wrong
I am working to get the package I support to support the 'distcheck'
target. The distcheck target fails with:
ERROR: files left in build directory after distclean:
./GraphicsMagick-1.1-20031209.tar.gz
Unlike the many other problems that I have already had to solve, this
one look
On Tue, 9 Dec 2003, David Wolfe wrote:
> > AFAIK There's a third possibility : you could setup a dist-hook target
> > in Makefile.am which allows you to specify completely your dist rule
>
> I suspect I'm too lazy for that. ;-) Seems like it would be more fun to
> take a stab at hacking automake
> > ... moving everything into the top-level dir (#1) did solve the
> > problem. Unfortunately, I don't currently have any control over the
> > directory structure (the motivation behind the attempt is to keep
> > platform specific items, i.e. *nix makefiles, VC++ 6 project files,
> > etc. in
AFAIK There's a third possibility : you could setup a dist-hook target
in Makefile.am which allows you to specify completely your dist rule (I
had the same problem than yours and used this method). Unfortunately, it
also means that you might have to update this rule each time you change
metadata in
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Ralf> Hi there,
Ralf> With current CVS automake, 'make distcheck' fails on automake,
On which OS? with which version of Make, sh, etc.?
Ralf> because readonly file version.texi in readonly directory
Ralf> cannot be written to.
Ralf>
On Wed, 2003-12-10 at 05:06, Tom Tromey wrote:
> It isn't impossible. I once wrote up some ideas along these lines:
>
> http://sources.redhat.com/ml/automake/2001-07/msg00248.html
>
> Obviously I never got around to implementing this :-)
Have you looked at either of my proof-of-concepts?
On Tue, 2003-12-09 at 09:27, Tom Tromey wrote:
> Yeah, you can do this. It's a bit more idiomatic to list header
> files in a _SOURCES somewhere. They are ignored for purposes of
> compilation, but are distributed.
Thanks for the advice - I'll move the header files into the _SOURCES
list.
Best
Thanks for the response!
On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote:
> i see from the previous post that you use a "manual VPATH" methodology.
> there are two approaches you can try:
>
> 1/ undo the unorthodoxy (move auto* files to top-level dir)
> 2/ prefix relative paths (such as "../.
Hi Bob, thanks for your reply.
Bob Friesenhahn ([EMAIL PROTECTED]):
> On Tue, 9 Dec 2003, Billy Biggs wrote:
>
> > I have a C program that uses a library which internally uses C++,
> > [...]
> >
> > 1. Why does my program need to be linked with a C++ compiler in
> > some cases and not in o
On Tue, 9 Dec 2003, Billy Biggs wrote:
> I have a C program that uses a library which internally uses C++, but
> exposes a C API. I have a user who experiences linking problems about
> missing standard C++ stuff, fixed by using "g++" to link. I am looking
> for help in understanding this and w
I have a C program that uses a library which internally uses C++, but
exposes a C API. I have a user who experiences linking problems about
missing standard C++ stuff, fixed by using "g++" to link. I am looking
for help in understanding this and what the correct solution is.
This has been di
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> the *_OBJECT definitions assume the absence of shell-active
Alexandre> characters in filenames, which is probably a safe
Alexandre> assumption for Makefiles.
It isn't unreasonable for a Java .class file's name to contain
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> In other words, dealing with junk like
Bob> apps_build_postgres_src_build_postgres_SOURCES
Bob> is very tiring and failure prone. Is there a reason why it can't
Bob> simply be
Bob> apps/build-postgres/src/build-postgres_SOURCES ?
Ye
On 9 Dec 2003, Tom Tromey wrote:
> > "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Bob> In other words, dealing with junk like
> Bob> apps_build_postgres_src_build_postgres_SOURCES
> Bob> is very tiring and failure prone. Is there a reason why it can't
> Bob> simply be
> Bob> apps/
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
"Marty" == Marty Leisner <[EMAIL PROTECTED]> writes:
adl> [...]
Marty> common/Makefile.am:1: directory should not contain `/'
Marty> Just wondering for some thoughts on this matter...is
Marty> there any reason to insist on sing
i see from the previous post that you use a "manual VPATH" methodology.
there are two approaches you can try:
1/ undo the unorthodoxy (move auto* files to top-level dir)
2/ prefix relative paths (such as "../../") w/ $(srcdir)
probably 1/ is the best for minimizing gray hairs long term, although
> "Jirka" == Jirka Hanika <[EMAIL PROTECTED]> writes:
Jirka> My view is that these (and other) problems disappear if you use a
Jirka> per-directory Makefile.am; but I also see the benefits (esp. compilation
Jirka> speed) of a non-recursive Makefile. So the solution could be to support
Jirka>
> "Scott" == J Scott Amort <[EMAIL PROTECTED]> writes:
Scott> - include
Scott> - src
Scott>- subdir1
Scott>- subdir2
Scott> - extra
Scott> - build
Scott>- src
Scott> The configure.ac, Makefile.am, etc. files are located in the
Scott> src subdirectory of the build directory at the
Denis Barbier wrote on 2003-11-12:
> > The 8-year old way of distributing a PO file directory has several drawbacks:
> > - requires separate files (POTFILES.in, Makevars) for customization,
>
> I can hardly see why this is a drawback. You added support for a
> separate po/LINGUAS file in 0.11, an
Akim Demaille wrote:
> But I hear your point, I just beg to differ on the relative
> importance.
I tend to agree. It's more important to make automake support po/ directories
in an easier way _in_general_ (and get rid of gettextize). A proposal in this
direction is at http://mail.gnu.org/archive/h
Hi there,
With current CVS automake, 'make distcheck' fails on automake,
because readonly file version.texi in readonly directory
cannot be written to.
I suppose the change from 2003-11-08 caused this, but as I don't
understand all the implications, I won't suggest a fix.
Regards,
Ralf
[ after
> Hi,
> Akim Demaille wrote:
>> > It is possible to do the internationalization in such a way, that
>> > automake would still run without libintl-perl being installed.
>> > License problems should not be an issue, libintl-perl is distributed
>> > under the LGPL. As for the required Perl ver
23 matches
Mail list logo
