Hello,
as Bruno said, ``GCS doesn't mandate that the build will break.''
I think we could be more careful and include some workarounds.
Generally, there are two problem situations:
Problem A:
a script.sh.in starts with
prefix = @prefix@
doc = @docdir@
this has to be fixed by adding `dataroot
Hi Stepan, Noah,
Thanks to both of you for the analyses!
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 02:17:53PM CEST:
>
> Problem A:
> a script.sh.in starts with
>
> prefix = @prefix@
> doc = @docdir@
But maybe that would have to be
prefix="@prefix@"
doc="@docdir@"
or similarly. This is
Hi,
Sorry to bother.
I tried to use automake to generate Makefile. But it kept reports as
following:
[EMAIL PROTECTED] gtkmm]$ aclocal;autoconf
[EMAIL PROTECTED] gtkmm]$ automake -a -c
Deep recursion on subroutine "Automake::read_am_file" at
/usr/bin/automake line 7254, line 1.
Can't locate C
Hi Erming,
Please, next time don't cross post a question to so many lists.
Just one is enough.
* Erming Pei wrote on Wed, Apr 12, 2006 at 03:07:45PM CEST:
> [EMAIL PROTECTED] gtkmm]$ automake -a -c
> Deep recursion on subroutine "Automake::read_am_file" at
> /usr/bin/automake line 7254, line 1
Ed Hartnett wrote:
> To accommodate this on machines with disk quotas, I want to allow the
> user to specify to configure a directory in which large files can be
> created during testing.
You might look into just having the user set TMPDIR (or through your
configure option) to the directory for h
Hi Ralf,
I'm very sorry for cross sending the question to 2 or more lists.
Thank you very much for helping me solve the problem so rapidly.
Also thank you for reminding me. I just didnt know which one could
work.
It wont happen again. :)
Cheers,
Erming.
Ralf Wildenhues wrote:
Hi
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 02:17:53PM CEST:
> The proposal
>
>http://lists.gnu.org/archive/html/bug-autoconf/2005-03/msg00027.html
>
> goes in this direction, but needs more work, as Bruno said.
> I might do that work when we come to an agreement what we want.
I know you wo
Hello,
On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
> here's a patch that I think does more or less what Bruno's patch
> intends to do, against current CVS.
I worked on the same issue. We both use the same pattern
`sed -n '/@datadir@/p;/@docdir@/p;/@infodir@/p...' ...
Hi Stepan,
* Stepan Kasal wrote on Wed, Apr 12, 2006 at 09:47:36PM CEST:
> On Wed, Apr 12, 2006 at 08:45:04PM +0200, Ralf Wildenhues wrote:
> > here's a patch that I think does more or less what Bruno's patch
> > intends to do, against current CVS.
>
> I worked on the same issue [..]
and your pa
Hi,
I want to upgrade to a fairly recent, trusted GNU auto tools
combination, could you advice? I might be wrong, but from my limited
experience not all automake/autoconf/libtool combinations play well.
Specifically I need good support for creating shared libraries for
AIX, Mac OS X, HP-UX, Sola
Hi Kent,
* Kent Boortz wrote on Wed, Apr 12, 2006 at 11:54:10PM CEST:
>
> I want to upgrade to a fairly recent, trusted GNU auto tools
> combination, could you advice? I might be wrong, but from my limited
> experience not all automake/autoconf/libtool combinations play well.
Autoconf-2.59, Auto
I'm working on moving a project over to automake/libtool right now.
There's perl modules in some subdirectories with their own Makefile.PL's.
Is there already some m4 macros around that will let me build perl
modules from automake? Or any other projects doing the same thing I could
On Wed, 12 Apr 2006, Tyler MacDonald wrote:
I'm working on moving a project over to automake/libtool right now.
There's perl modules in some subdirectories with their own Makefile.PL's.
Is there already some m4 macros around that will let me build perl
modules from automake? Or
Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> Interfacing between Automake and ExtUtils::MakeMaker is a bloody
> disaster. They do not support the same paradigm or targets.
> MakeMaker does weird things like having 'make clean' remove the
> Makefile. MakeMaker is inconsistent between Perl relea
On Wed, 12 Apr 2006, Tyler MacDonald wrote:
What I'd really like (whether I have to write it myself or somebody
has already done it for me ) is to have automake invoke
Makefile.PL/Makefile (and possibly Build.PL/Build) in the correct way when I
tell it that a subdirectory is a perl module
Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> This is a problem since MakeMaker makes no provision for using
> uninstalled libraries. The only way it works reliably is if the
> libraries are installed. Regardless, I have found ways to use
> uninstalled libraries if the Perl extension is built a
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Wed, 12 Apr 2006, Tyler MacDonald wrote:
>> And find some way for makemaker to treat those SUBDIRS as "black
>> box" perl modules. I'd also like some way to pass extra arguments into the
>> Makefile.PL/Build.PL to pull in libraries elsewhere in
On Wed, 12 Apr 2006, Russ Allbery wrote:
# If I don't tell MakeMaker about the full path to the just-built library, it
# will helpfully delete the -lwebauth reference and then create a broken
# module, while saying that this is probably harmless. If I do include it, I
I recall that some versio
On Wed, 12 Apr 2006, Tyler MacDonald wrote:
Libtool puts a valid .so somewhere for me already, so this is what
I'm doing for that right now:
Net-BitTorrent-LibBTT/Makefile: Net-BitTorrent-LibBTT/Makefile.PL
cd Net-BitTorrent-LibBTT && $(PERL) Makefile.PL \
CCFLAGS="-I../.
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Wed, 12 Apr 2006, Russ Allbery wrote:
>> # If I don't tell MakeMaker about the full path to the just-built
>> # library, it will helpfully delete the -lwebauth reference and then
>> # create a broken module, while saying that this is probably harmle
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> But is not portable. Systems which automatically remember shared
> library dependencies may cause problems since the installed module is
> referencing libraries which no longer exist or have been
> moved. Sometimes libtool must re-link shared librarie
Hi Russ,
* Russ Allbery wrote on Thu, Apr 13, 2006 at 05:12:34AM CEST:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Systems which automatically remember shared library dependencies may
> > cause problems since the installed module is referencing libraries
> > which no longer exist or have
22 matches
Mail list logo
