Scott Kostyshak wrote:
An alternative that suggests both ./configure and make but does not run make
on a failed configure is:
run ./configure make [autogen_alt.patch]
It is in. P
Scott Kostyshak wrote:
> An alternative that suggests both ./configure and make but does not run make
> on a failed configure is:
> <> [autogen_alt.patch]
It is in. P
If autogen.sh completes successfully, it outputs run ./configure ; make. I do
not think this is good advice because what if configure has an error? The
make command will still run.
I suggest:
You can now run ./configure [autogen.patch]
because upon successful exit, configure tells you to run
If autogen.sh completes successfully, it outputs "run ./configure ; make". I do
not think this is good advice because what if configure has an error? The
"make" command will still run.
I suggest:
<> [autogen.patch]
because upon successful exit, configure tells you to
Hi all,
when configuring LyX for development, I can see this:
$ ./autogen.sh
Using automake (GNU automake) 1.11.1
Using autoconf (GNU Autoconf) 2.67
Building macros...
/usr/share/aclocal/gtkglextmm-1.2.m4:225: warning: underquoted
definition of AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD
/usr/share
Le 27/05/2011 08:29, Tommaso Cucinotta a écrit :
Hi all,
when configuring LyX for development, I can see this:
/usr/share/aclocal/gtkglextmm-1.2.m4:225: warning: underquoted
definition of AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD
is that normal ? Why is gtkglext coming in the loop ? I don't expect
Hi all,
when configuring LyX for development, I can see this:
$ ./autogen.sh
Using automake (GNU automake) 1.11.1
Using autoconf (GNU Autoconf) 2.67
Building macros...
/usr/share/aclocal/gtkglextmm-1.2.m4:225: warning: underquoted
definition of AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD
/usr/share
Le 27/05/2011 08:29, Tommaso Cucinotta a écrit :
Hi all,
when configuring LyX for development, I can see this:
/usr/share/aclocal/gtkglextmm-1.2.m4:225: warning: underquoted
definition of AC_GTKGLEXTMM_SUPPORTS_MULTIHEAD
is that normal ? Why is gtkglext coming in the loop ? I don't expect
configure and
autogen.sh:
configure says:
stef...@polus:~/temp/lyx-devel/trunk$ ./configure
./configure: line 1875: LYX_CHECK_VERSION: command not found
./configure: line 1876: LYX_VERSION_SUFFIX: command not found
checking build system type... x86_64-unknown-linux-gnu
checking host system type
Using automake (GNU automake) 1.7.9
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's the cause we should update our requirements (or revert
something else), but 1.7.9 is approximately 6 years old.
Vincent
On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
Using automake (GNU automake) 1.7.9
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's the cause we should update our requirements (or revert
something else), but
Thanks for the pointer. It turns out automake 1.10 causes
problems in Ubuntu, so it is not installed by default. The
default is what I had, 1.7.9. After installing 1.10, all
problems disappeared and Lyx-trunk is being compiled
A quick check reveals:
$aclocal-1.7 -I m4 -I config
aclocal: macro
Thanks for the pointer. It turns out automake 1.10 causes
problems in Ubuntu, so it is not installed by default. The
default is what I had, 1.7.9. After installing 1.10, all
problems disappeared and Lyx-trunk is being compiled
A quick check reveals:
$aclocal-1.7 -I m4 -I config
Le 27/08/2009 18:52, Stefano Franchi a écrit :
On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's the cause we should update our requirements (or revert
something else),
Le 27/08/2009 19:26, rgheck a écrit :
So, it seems we should require automake 1.8 at least.
Any other opinions on this? Enrico? JMarc?
The reason is gettext. The NEWS from version 0.14.7 (we use 0.16.1) says:
* The gettext autoconf macros now assume 'aclocal' from automake 1.8 or
newer.
Jean-Marc Lasgouttes schreef:
Le 27/08/2009 19:26, rgheck a écrit :
So, it seems we should require automake 1.8 at least.
Any other opinions on this? Enrico? JMarc?
The reason is gettext. The NEWS from version 0.14.7 (we use 0.16.1) says:
* The gettext autoconf macros now assume 'aclocal'
On Thursday 27 August 2009 05:50:07 pm Jean-Marc Lasgouttes wrote:
Le 27/08/2009 18:52, Stefano Franchi a écrit :
On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's
configure and
autogen.sh:
configure says:
stef...@polus:~/temp/lyx-devel/trunk$ ./configure
./configure: line 1875: LYX_CHECK_VERSION: command not found
./configure: line 1876: LYX_VERSION_SUFFIX: command not found
checking build system type... x86_64-unknown-linux-gnu
checking host system type
> Using automake (GNU automake) 1.7.9
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's the cause we should update our requirements (or revert
something else), but 1.7.9 is approximately 6 years old.
Vincent
On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
> > Using automake (GNU automake) 1.7.9
>
> I think you might want to try a newer version of automake. Something
> like 1.10 would do.
>
> If that's the cause we should update our requirements (or revert
> something else),
>Thanks for the pointer. It turns out automake 1.10 causes
>problems in Ubuntu, so it is not installed by default. The
>default is what I had, 1.7.9. After installing 1.10, all
>problems disappeared and Lyx-trunk is being compiled
A quick check reveals:
$aclocal-1.7 -I m4 -I config
aclocal:
Thanks for the pointer. It turns out automake 1.10 causes
problems in Ubuntu, so it is not installed by default. The
default is what I had, 1.7.9. After installing 1.10, all
problems disappeared and Lyx-trunk is being compiled
A quick check reveals:
$aclocal-1.7 -I m4 -I config
Le 27/08/2009 18:52, Stefano Franchi a écrit :
On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
I think you might want to try a newer version of automake. Something
like 1.10 would do.
If that's the cause we should update our requirements (or revert
something else),
Le 27/08/2009 19:26, rgheck a écrit :
So, it seems we should require automake 1.8 at least.
Any other opinions on this? Enrico? JMarc?
The reason is gettext. The NEWS from version 0.14.7 (we use 0.16.1) says:
* The gettext autoconf macros now assume 'aclocal' from automake 1.8 or
newer.
Jean-Marc Lasgouttes schreef:
Le 27/08/2009 19:26, rgheck a écrit :
So, it seems we should require automake 1.8 at least.
Any other opinions on this? Enrico? JMarc?
The reason is gettext. The NEWS from version 0.14.7 (we use 0.16.1) says:
* The gettext autoconf macros now assume 'aclocal'
On Thursday 27 August 2009 05:50:07 pm Jean-Marc Lasgouttes wrote:
> Le 27/08/2009 18:52, Stefano Franchi a écrit :
> > On Thursday 27 August 2009 11:27:17 am Vincent van Ravesteijn - TNW wrote:
> >> I think you might want to try a newer version of automake. Something
> >> like 1.10 would do.
> >>
Stefan Schimanski [EMAIL PROTECTED] writes:
cmake is broken now by that.
It seems that Abdel 'solved' the problem by removing the use of
included-gettext with cmake, but I'd be interested to know what the
problem was.
JMarc
Stefan Schimanski <[EMAIL PROTECTED]> writes:
> cmake is broken now by that.
It seems that Abdel 'solved' the problem by removing the use of
included-gettext with cmake, but I'd be interested to know what the
problem was.
JMarc
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Abdel.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error? I am going to put
it back anyway...
JMarc
Jean-Marc Lasgouttes wrote:
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error?
No, this is a one time thing to do. As a Windows developer (shame on me)
I don't see this as a problem as we have to install the support
libraries
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
It's very strange. In fact -liconv is part of the linker command
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
It's very strange. In fact -liconv is part
Am 09.06.2008 um 09:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found
when calling cmake.
Works fine on Windows. Maybe try to upgrade libintl
Stefan Schimanski wrote:
Am 09.06.2008 um 09:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe
Am Monday 09 June 2008 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error?
No, this is a one time thing to do. As a Windows developer (shame on me)
I don't see this as a
Kornel Benko wrote:
Am Monday 09 June 2008 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error?
No, this is a one time thing to do. As a Windows developer
:
$ ./autogen.sh
Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.60
Copying gettext code...
autopoint: *** infrastructure files for version 0.14.5 not found; this is
autopoint from GNU gettext-tools 0.14.1
autopoint: *** Stop.
Building macros...
Building config header template...
Building
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Abdel.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error? I am going to put
it back anyway...
JMarc
Jean-Marc Lasgouttes wrote:
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error?
No, this is a one time thing to do. As a Windows developer (shame on me)
I don't see this as a problem as we have to install the support
libraries
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
It's very strange. In fact -liconv is part of the linker command
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe try to upgrade libintl and iconv?
It's very strange. In fact -liconv is part
Am 09.06.2008 um 09:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found
when calling cmake.
Works fine on Windows. Maybe try to upgrade libintl
Stefan Schimanski wrote:
Am 09.06.2008 um 09:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.06.2008 um 08:28 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
It seems he does not link against iconv, although it is found when
calling cmake.
Works fine on Windows. Maybe
Am Monday 09 June 2008 schrieb Abdelrazak Younes:
> Jean-Marc Lasgouttes wrote:
> >> Works fine on Windows. Maybe try to upgrade libintl and iconv?
> >
> > Do you see now why removing gettext was an error?
>
> No, this is a one time thing to do. As a Windows developer (shame on me)
> I don't see
Kornel Benko wrote:
Am Monday 09 June 2008 schrieb Abdelrazak Younes:
Jean-Marc Lasgouttes wrote:
Works fine on Windows. Maybe try to upgrade libintl and iconv?
Do you see now why removing gettext was an error?
No, this is a one time thing to do. As a Windows developer
test Solaris 10:
$ ./autogen.sh
Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.60
Copying gettext code...
autopoint: *** infrastructure files for version 0.14.5 not found; this is
autopoint from GNU gettext-tools 0.14.1
autopoint: *** Stop.
Building macros...
Building config header templ
it.
* autogen.sh: use autopoint to poulate the gettext code; simplify.
* po/Rules-lyx: move the LyX-specific code of the Makefile here.
* configure.ac: add magic incantation telling autopoint to import
gettext 0.16.1. Generate config.h in toplevel directory to please
Stefan Schimanski wrote:
cmake is broken now by that.
Please try again.
Abdel.
It seems he does not link against iconv, although it is found when
calling cmake.
Stefan
Ld /Users/sts/Quellen/mac/lyx-scope-dynmacro/build/bin/Debug/tex2lyx
normal i386
cd /Users/sts/Quellen/mac/lyx-scope-dynmacro/build
/Developer/usr/bin/g++-4.0 -arch i386
it.
* autogen.sh: use autopoint to poulate the gettext code; simplify.
* po/Rules-lyx: move the LyX-specific code of the Makefile here.
* configure.ac: add magic incantation telling autopoint to import
gettext 0.16.1. Generate config.h in toplevel directory to please
Stefan Schimanski wrote:
cmake is broken now by that.
Please try again.
Abdel.
It seems he does not link against iconv, although it is found when
calling cmake.
Stefan
Ld /Users/sts/Quellen/mac/lyx-scope-dynmacro/build/bin/Debug/tex2lyx
normal i386
cd /Users/sts/Quellen/mac/lyx-scope-dynmacro/build
/Developer/usr/bin/g++-4.0 -arch i386
[EMAIL PROTECTED] writes:
Author: lasgouttes
Date: Fri Jun 6 17:25:55 2008
New Revision: 25167
URL: http://www.lyx.org/trac/changeset/25167
Log:
Remove our in tree gettext version and replace with a mechanism to import it.
* autogen.sh: use autopoint to poulate the gettext code
with a mechanism to import
it.
* autogen.sh: use autopoint to poulate the gettext code; simplify.
* po/Rules-lyx: move the LyX-specific code of the Makefile here.
* configure.ac: add magic incantation telling autopoint to import
gettext 0.16.1. Generate config.h
surprised.
Please run ./autogen.sh before proceeding. It is also a good idea to
make sure that you remove src/config.h if you have it (or to start
from a fresh tree).
I'm also getting this error on configure:
config.status: error: cannot find input file: intl/Makefile.in
Did you run
./autogen.sh before proceeding. It is also a good idea to
make sure that you remove src/config.h if you have it (or to start
from a fresh tree).
I'm also getting this error on configure:
config.status: error: cannot find input file: intl/Makefile.in
Did you run autogen.sh?
Yes
Jean-Marc Lasgouttes wrote:
* remove all files that came from a gettext distribution.
Now autoconf users will need the relevant gettext packages at autogen
time. I settled on version 0.16.1 of gettext, if it is too new for
some people we can go back in time a bit.
can you be more
[EMAIL PROTECTED] wrote:
Author: lasgouttes
Date: Fri Jun 6 17:25:55 2008
New Revision: 25167
URL: http://www.lyx.org/trac/changeset/25167
Log:
Remove our in tree gettext version and replace with a mechanism to import it.
currently i'm not able to compile anymore.
autogen log is in
Pavel Sanda [EMAIL PROTECTED] writes:
can you be more verbose what is now needed to build lyx wrt gettext versions?
0.17 will work? do you intend to care about fixes for new gettext versions?
Believe it or not, each gettext version contains a cvs repository with
all versions of the gettext
Pavel Sanda [EMAIL PROTECTED] writes:
Here is the culprit.
Copying gettext code...
autopoint: *** cvs program not found
autopoint: *** Stop.
So you need to install cvs :)
JMarc
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Therefore, if you have gettext 0.17, you will automatically get the
0.16.1 version of the files that configure.ac requests.
The result is that we decide on a version and everybody will use this
same version.
JMarc
Pavel Sanda wrote:
[EMAIL PROTECTED] wrote:
Author: lasgouttes
Date: Fri Jun 6 17:25:55 2008
New Revision: 25167
URL: http://www.lyx.org/trac/changeset/25167
Log:
Remove our in tree gettext version and replace with a mechanism to import it.
currently i'm not able to compile anymore.
to run autogen.sh then?
what exactly is the gain of this gettext patch?
pavel
Pavel Sanda [EMAIL PROTECTED] writes:
grrr. this weird dependency is a joke?
any time i'm out of connection i'm not able to run autogen.sh then?
No, you did not run my earlier message: the gettext distribution
contains a cvs _repository_ that is used in local to fetch any old
version
Jean-Marc Lasgouttes wrote:
grrr. this weird dependency is a joke?
any time i'm out of connection i'm not able to run autogen.sh then?
No, you did not run my earlier message: the gettext distribution
contains a cvs _repository_ that is used in local to fetch any old
version
Pavel Sanda [EMAIL PROTECTED] writes:
i still don't see the gain :) what bug it fixes? i can't remember
that i needed cvs to run autogen for any package on linux.
I might not have chosen the right solution. The different solutions
are given here
Bennett Helm wrote:
(OS X's automake is 1.10 and autoconf is 2.61.)
Here (on 10.4.11):
$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.59
khofbaue-al:~ khofbaue$ /usr/bin/automake --version
automake (GNU automake) 1.6.3
/Konrad
Bennett Helm wrote:
OS X 10.5 comes with gettext 0.14.5;
Are you sure about that ???
If it sits in /usr/local/bin, then this is very likely not the case.
I just checked, it is the MacTex-2007 package that installs this old
version 0.14.5 of gettext. Mac OS X by itself comes without gettext.
[EMAIL PROTECTED] writes:
> Author: lasgouttes
> Date: Fri Jun 6 17:25:55 2008
> New Revision: 25167
>
> URL: http://www.lyx.org/trac/changeset/25167
> Log:
> Remove our in tree gettext version and replace with a mechanism to import it.
>
> * autogen.s
> Log:
> > Remove our in tree gettext version and replace with a mechanism to import
> it.
> >
> > * autogen.sh: use autopoint to poulate the gettext code; simplify.
> >
> > * po/Rules-lyx: move the LyX-specific code of the Makefile here.
> >
> &
still maintained? I am very surprised.
>> Please run ./autogen.sh before proceeding. It is also a good idea to
>> make sure that you remove src/config.h if you have it (or to start
>> from a fresh tree).
>
>
> I'm also getting this error on configure:
>
> config.
gettext/
.
Maintainer: Fink Core Group <[EMAIL PROTECTED]>
>> Please run ./autogen.sh before proceeding. It is also a good idea to
> >> make sure that you remove src/config.h if you have it (or to start
> >> from a fresh tree).
> >
> >
> > I'm al
Jean-Marc Lasgouttes wrote:
> > * remove all files that came from a gettext distribution.
>
> Now autoconf users will need the relevant gettext packages at autogen
> time. I settled on version 0.16.1 of gettext, if it is too new for
> some people we can go back in time a bit.
can you be more
[EMAIL PROTECTED] wrote:
> Author: lasgouttes
> Date: Fri Jun 6 17:25:55 2008
> New Revision: 25167
>
> URL: http://www.lyx.org/trac/changeset/25167
> Log:
> Remove our in tree gettext version and replace with a mechanism to import it.
currently i'm not able to compile anymore.
autogen log is
Pavel Sanda <[EMAIL PROTECTED]> writes:
> can you be more verbose what is now needed to build lyx wrt gettext versions?
> 0.17 will work? do you intend to care about fixes for new gettext versions?
Believe it or not, each gettext version contains a cvs repository with
all versions of the gettext
Pavel Sanda <[EMAIL PROTECTED]> writes:
Here is the culprit.
> Copying gettext code...
> autopoint: *** cvs program not found
> autopoint: *** Stop.
So you need to install cvs :)
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Therefore, if you have gettext 0.17, you will automatically get the
> 0.16.1 version of the files that configure.ac requests.
The result is that we decide on a version and everybody will use this
same version.
JMarc
Pavel Sanda wrote:
[EMAIL PROTECTED] wrote:
Author: lasgouttes
Date: Fri Jun 6 17:25:55 2008
New Revision: 25167
URL: http://www.lyx.org/trac/changeset/25167
Log:
Remove our in tree gettext version and replace with a mechanism to import it.
currently i'm not able to compile anymore.
rd dependency is a joke?
any time i'm out of connection i'm not able to run autogen.sh then?
what exactly is the gain of this gettext patch?
pavel
Pavel Sanda <[EMAIL PROTECTED]> writes:
> grrr. this weird dependency is a joke?
> any time i'm out of connection i'm not able to run autogen.sh then?
No, you did not run my earlier message: the gettext distribution
contains a cvs _repository_ that is used in local to fetch any
Jean-Marc Lasgouttes wrote:
> > grrr. this weird dependency is a joke?
> > any time i'm out of connection i'm not able to run autogen.sh then?
>
> No, you did not run my earlier message: the gettext distribution
> contains a cvs _repository_ that is used in local to fe
Pavel Sanda <[EMAIL PROTECTED]> writes:
> i still don't see the gain :) what bug it fixes? i can't remember
> that i needed cvs to run autogen for any package on linux.
I might not have chosen the right solution. The different solutions
are given here
Bennett Helm wrote:
(OS X's automake is 1.10 and autoconf is 2.61.)
Here (on 10.4.11):
$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.59
khofbaue-al:~ khofbaue$ /usr/bin/automake --version
automake (GNU automake) 1.6.3
/Konrad
Bennett Helm wrote:
OS X 10.5 comes with gettext 0.14.5;
Are you sure about that ???
If it sits in /usr/local/bin, then this is very likely not the case.
I just checked, it is the MacTex-2007 package that installs this old
version 0.14.5 of gettext. Mac OS X by itself comes without gettext.
Downloaded a fresh copy of the current trunk, and got an error on
autogen.sh: src/frontends/qt4/ui/Makefile.in not found.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck
Downloaded a fresh copy of the current trunk, and got an error on
autogen.sh: src/frontends/qt4/ui/Makefile.in not found.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck
will be rebuilt automatically when a m4 file changes. This
lasgouttes means that running autogen.sh should not be needed anymore
lasgouttes (famous last words!).
I finally took the time to read the automake docs and clean this code.
Just run ./autogen.sh one last time (!) and now everything should
lasgouttes aclocal -I config instead of acinclude.m4. Now configure
lasgouttes will be rebuilt automatically when a m4 file changes. This
lasgouttes means that running autogen.sh should not be needed anymore
lasgouttes (famous last words!).
I finally took the time to read the automake docs and clean
lasgouttes aclocal -I config instead of acinclude.m4. Now configure
lasgouttes will be rebuilt automatically when a m4 file changes. This
lasgouttes means that running autogen.sh should not be needed anymore
lasgouttes (famous last words!).
I finally took the time to read the automake docs and clean
On Thu, Apr 26, 2007 at 02:55:57PM +0200, Andre Poenitz wrote:
Could you take out libtools?
Why?
--
Enrico
Enrico Forestieri wrote:
On Thu, Apr 26, 2007 at 02:55:57PM +0200, Andre Poenitz wrote:
Could you take out libtools?
Why?
Because it's dead slow and unneeded?
:-)
Abdel.
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Let's see now if I can do something about broken dependencies.
Andre Could you take out libtools?
I'm afraid I do not know how to do that. But I would be very
interested by such feature.
I found projects that implement a --disable-libtool
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico When running autogen.sh I get the following:
Enrico $ ./autogen.sh Using automake (GNU automake) 1.9 Using
Enrico autoconf (GNU Autoconf) 2.59 -n Locating GNU m4...
Enrico /usr/sfw/bin/gm4 Building macros... . done. Building config
On Thu, Apr 26, 2007 at 03:33:59PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Thu, Apr 26, 2007 at 02:55:57PM +0200, Andre Poenitz wrote:
Could you take out libtools?
Why?
Because it's dead slow and unneeded?
:-)
This is your opinion, of course ;-)
I agree about
On Thu, Apr 26, 2007 at 03:44:30PM +0200, Jean-Marc Lasgouttes wrote:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico When running autogen.sh I get the following:
Enrico $ ./autogen.sh Using automake (GNU automake) 1.9 Using
Enrico autoconf (GNU Autoconf) 2.59 -n Locating GNU
On Thursday 26 April 2007 2:44:30 pm Jean-Marc Lasgouttes wrote:
This is very weird, since this AM_CONDITIONAL appears in
lyxinclude.m4/LYX_USE_PACKAGING. What packaging do you use? windows or
posix?
This happens to me in linux, everything that Enrico reports.
--
José Abílio
Enrico Forestieri wrote:
On Thu, Apr 26, 2007 at 03:33:59PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Thu, Apr 26, 2007 at 02:55:57PM +0200, Andre Poenitz wrote:
Could you take out libtools?
Why?
Because it's dead slow and unneeded?
:-)
This is your opinion, of course
José == José Matos [EMAIL PROTECTED] writes:
José On Thursday 26 April 2007 2:44:30 pm Jean-Marc Lasgouttes wrote:
This is very weird, since this AM_CONDITIONAL appears in
lyxinclude.m4/LYX_USE_PACKAGING. What packaging do you use? windows
or posix?
José This happens to me in linux,
1 - 100 of 488 matches
Mail list logo
