Re: Builds with 'configure' not at the top of srcdir

tomake and Autoconf (and all the stuff _they_ depend on, > notably M4 and Perl), before they could install any _other_ GNU software, > would've been a non-starter > > So, all the generated code assumes that the location of the configure script > *defines* the top level of the s

Re: Builds with 'configure' not at the top of srcdir

software, would've been a non-starter. So, all the generated code assumes that the location of the configure script *defines* the top level of the source tree. The `--srcdir` option is only intended for use as a manual override when the automatic probe for the location of the configure

Builds with 'configure' not at the top of srcdir

Hello, I've been trying to separate the build system and source directory completely. Part of that would be to have the 'configure' script in the 'build' directory, away from the 'src' directory The issue is that when I run `./configure --srcdir=../src`

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

On Tue, 5 Jan 2021, Zack Weinberg wrote: Something I found which surprised me is that Automake has added a GNU COPYING file to my non-GNU non-GPL package. Once the file appeared in the source directory, it seems that it continued to be used and included in spite of the Automake options provide

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

On Tue, Jan 5, 2021 at 8:43 AM Bob Friesenhahn wrote: > On Mon, 4 Jan 2021, Zack Weinberg wrote: > >> > >> Something which surprises me is that the distribution tarballs became > >> noticeably larger. > > > > This is expected. The bulk of the increase is probably due to the test > > programs used

srcdir could lead distcheck to a corrupted tarball

Hi all, I've been hardly beaten by the issue described here: http://lists.gnu.org/archive/html/automake/2006-09/msg8.html I still think that is a clean bug. From what I understood, VPATH and srcdir are both ".." during distcheck, so also "../.." (that is the direc

Re: $(srcdir)/foo is not generated because $(srcdir)/$(srcdir)/foo exists

parse things reliably. Thanks for your suggestions; I've implemented them. else ## this is needed in 'svn export' build $(srcdir)/.revision: echo ""> $@ I don't see why you should need this rule here. The .revision file is distributed, so it should already

Re: $(srcdir)/foo is not generated because $(srcdir)/$(srcdir)/foo exists

ision', with current revision number and from this is a C > header file `revision.h' created. Then to test that things work as > I'd like I have target similar to distcheck that essentially does > > svn export $(srcdir) _exported > cd _exported > ./bootstrap > mkdir

$(srcdir)/foo is not generated because $(srcdir)/$(srcdir)/foo exists

test that things work as I'd like I have target similar to distcheck that essentially does svn export $(srcdir) _exported cd _exported ./bootstrap mkdir _build cd _build ../configure make make check When doing that here I get the following error: revision=$(cat ../.revision) \ &&am

bug#7833: automake uses two different values for DejaGNU srcdir

nt you are trying to make with your >> example. A relative srcdir will sometimes work and sometimes fail. It >> seemed to me an absolute srcdir should always work, but Ralf has pointed >> out a somewhat obscure case where it too can fail. Either way, it makes >> no sense for a

bug#7833: automake uses two different values for DejaGNU srcdir

gt; (for me at least)? > >> > >> I guess I'm not sure what point you are trying to make with your > >> example. A relative srcdir will sometimes work and sometimes fail. It > >> seemed to me an absolute srcdir should always work, but Ralf has pointed

bug#7833: automake uses two different values for DejaGNU srcdir

On Thursday 13 January 2011, Ian Lance wrote: > Stefano Lattarini writes: > > > Are you sure about this? Why then is the attached testcase working > > (for me at least)? > > I guess I'm not sure what point you are trying to make with your > example. A relativ

bug#7833: automake uses two different values for DejaGNU srcdir

Stefano Lattarini writes: > Are you sure about this? Why then is the attached testcase working > (for me at least)? I guess I'm not sure what point you are trying to make with your example. A relative srcdir will sometimes work and sometimes fail. It seemed to me an absolute sr

bug#7833: automake uses two different values for DejaGNU srcdir

When automake is configured to use DejaGNU, it uses two different values for srcdir. There are two different cases in lib/am/dejagnu.am: The first is in check-DEJAGNU: check-DEJAGNU: site.exp ## Life is easiest with an absolute srcdir, so do that. srcdir=`$(am__cd) $(srcdir) &&

Re: Include files outside srcdir?

* Peter Johansson wrote on Wed, Nov 04, 2009 at 01:55:21PM CET: > Ralf Wildenhues wrote: > >* Peter Johansson wrote on Tue, Nov 03, 2009 at 07:31:56PM CET: > >>http://www.nongnu.org/autoconf-archive/ax_add_am_macro_static.html > >Hmm, the idea of having such a is not bad, but I don't think it shou

Re: Include files outside srcdir?

in wrote: > >I have a number of autotooled libraries. Currently their Makefile.am's > >... Can you show a small example that doesn't work? Thanks. > > The documentation says > >automake only pays attention to includes that start with $(srcdir) or... But these two

Re: Include files outside srcdir?

Hi Ralf, Ralf Wildenhues wrote: * Peter Johansson wrote on Tue, Nov 03, 2009 at 07:31:56PM CET: I'm not sure exactly what you wanna achieve here. But there is an autoconf macro http://www.nongnu.org/autoconf-archive/ax_add_am_macro_static.html which allows you to have autoconf to generate au

Re: Include files outside srcdir?

e that doesn't work? Thanks. > > The documentation says > >automake only pays attention to includes that start with $(srcdir) or > >$(top_srcdir), but that's not possible in this instance, because each > >library is its own project (recursive make isn't be

Re: Include files outside srcdir?

observed by automake -- instead it's ignored and passed on to make, where it defines targets that make doesn't care about (install-exec-hook, etc.). The documentation says automake only pays attention to includes that start with $(srcdir) or $(top_srcdir), but that's not possible in this instan

Include files outside srcdir?

ead it's ignored and passed on to make, where it defines targets that make doesn't care about (install-exec-hook, etc.). The documentation says automake only pays attention to includes that start with $(srcdir) or $(top_srcdir), but that's not possible in this instance, because each li

Re: Make syntax $(srcdir) in Makefile.am problem

Am Dienstag, den 12.02.2008, 10:39 -0500 schrieb db: > I am trying to run automake command in Fedora 7 (automake 1.10). Automake > fails due to GNU make extension: > > priv/Makefile.am:52: shell cat $(srcdir: non-POSIX variable name > priv/Makefile.am:52: (probably a GNU

Re: Make syntax $(srcdir) in Makefile.am problem

* db wrote on Tue, Feb 12, 2008 at 04:39:58PM CET: > I am trying to run automake command in Fedora 7 (automake 1.10). Automake > fails due to GNU make extension: > > priv/Makefile.am:52: shell cat $(srcdir: non-POSIX variable name > priv/Makefile.am:52: (probably a GNU make ext

Make syntax $(srcdir) in Makefile.am problem

I am trying to run automake command in Fedora 7 (automake 1.10). Automake fails due to GNU make extension: priv/Makefile.am:52: shell cat $(srcdir: non-POSIX variable name priv/Makefile.am:52: (probably a GNU make extension) Makefile.am content, where the problem is: $(shell cat $(srcdir

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

>>> "HD" == Harald Dunkel <[EMAIL PROTECTED]> writes: HD> Hi folks, HD> Question about make depend: HD> If I set HD> SRCDIR = ../src HD> noinst_PROGRAMS = hello HD> hello_SOURCES = ${SRCDIR}/hello.c HD> in my Makefile.am, then make complains

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hello, On Tue, Sep 13, 2005 at 04:03:36PM +0200, Ralf Wildenhues wrote: > Anyway, the way the rule is now, if $LN_S is `cp', source files in > $(INTERFACE_DIR) newer than in `.' will not get copied, which is bad. well, I supposed that the development happens on system with symlinks. The fallbacks

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

* Stepan Kasal wrote on Tue, Sep 13, 2005 at 03:26:57PM CEST: > > > You don't need to copy headers. [...] > > So you can leave out the BUILT_SOURCES line completely. > > thanks for correcting me. > > > > $(linked_sources): > > > $(LN_S) '$(INTERFACE_DIR)/$@' '$@' > > > > But you need to "rm

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hello Harald, Ralf, > You don't need to copy headers. [...] > So you can leave out the BUILT_SOURCES line completely. thanks for correcting me. > > $(linked_sources): > > $(LN_S) '$(INTERFACE_DIR)/$@' '$@' > > But you need to "rm -f '$@'" before invoking $(LN_S). Why? If the file exists,

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hi Stepan, Harald, * Stepan Kasal wrote on Tue, Sep 13, 2005 at 02:21:43PM CEST: > On Tue, Sep 13, 2005 at 12:58:45PM +0200, Harald Dunkel wrote: > > > > linked_sources = common_interface.c more.c even-more.c > > > BUILT_SOURCES = $(linked_sources) > > > $(linked_sources): > > > list='$(l

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hello Harald, On Tue, Sep 13, 2005 at 12:58:45PM +0200, Harald Dunkel wrote: > Of course I appreciate your workaround, but please remember > that this thread is about generating a meaningfull error > message for a construct that autoconf/automake cannot > handle. But maybe there is a way to genera

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hi Ralf, Ralf Wildenhues wrote: > > How about using either > - a convenience archive, or > - one single large Makefile.am with subdir-objects > (see "info Automake Alternative") > A convenience library doesn't work, because I have pretty many different CPP defines, probably set either in conf

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hi Harald, * Harald Dunkel wrote on Tue, Sep 13, 2005 at 08:24:14AM CEST: > > I have some common source files that I have to compile and link > several times in different contexts. Actually the Makefile.am > files look more like this: > > hello_SOURCES = \ > $(INTERFACE_DIR)/c

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Bob Proulx wrote: > Harald Dunkel wrote: > >>Question about make depend: >> >>If I set >> >> SRCDIR = ../src >> noinst_PROGRAMS = hello >> hello_SOURCES = ${SRCDIR}/hello.c > > > Shouldn't you be using normal VPATH? T

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Harald Dunkel wrote: > Question about make depend: > > If I set > > SRCDIR = ../src > noinst_PROGRAMS = hello > hello_SOURCES = ${SRCDIR}/hello.c Shouldn't you be using normal VPATH? That is, you are setting hello_SOURCES = ../src/hello.c. But I

make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hi folks, Question about make depend: If I set SRCDIR = ../src noinst_PROGRAMS = hello hello_SOURCES = ${SRCDIR}/hello.c in my Makefile.am, then make complains Makefile:242: ../src/.deps/hello.Po: No such file or directory make[1]: *** No rule to make target `../src

Re: builddir vs. srcdir

Hello, On Fri, Mar 18, 2005 at 09:34:15PM +0200, Paul Pogonyshev wrote: > Sorry, but I'll stick with my setup. My parser depends on my lowest- > level library (`libutils') and almost the whole build-tree depends on > the generated files. So, when I touched my `libutils' in any way, I > would get

Re: builddir vs. srcdir

gt; .list.h: Makefile $(PARSE_LIST_COMMAND) > $(PARSE_LIST_BUILD_RULE) > PARSE_LIST_BUILD_RULE = \ > $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ > `test -f '$<' || echo '$(srcdir)/'`$< $*.h $*.c && \ >

Re: builddir vs. srcdir

akefile $(PARSE_LIST_COMMAND) $(PARSE_LIST_BUILD_RULE) PARSE_LIST_BUILD_RULE = \ $(PARSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) \ `test -f '$<' || echo '$(srcdir)/'`$< $*.h $*.c &&

Re: builddir vs. srcdir

RSE_LIST_COMMAND) $(PARSE_LIST_FLAGS) # We use `cmp' here to avoid unneeded recompilations of files that # depend on generated ones (only really useful for `.h' files.) # PARSE_LIST_BUILD_RULE = \ if $(PARSE_LIST) `test -f '$<' |

Re: builddir vs. srcdir

Hello, On Thu, Mar 10, 2005 at 10:05:51PM +0200, Paul Pogonyshev wrote: > I'm not sure which one comes first. [...] I can just do > > foo.c : foo.h > foo.c foo.h : ... > if $(BUILD_THEM_FILES) foo.list foo.h foo.c; then \ > touch foo.c;

Re: builddir vs. srcdir

> Hi, > > On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: > > > And I'd like to suggest that you use SUFFIXES to handle the .list > > > source. Please look at the following example: > > > > Well, my generator is even more non-standard, since I need to pass an > > additional comma

Re: builddir vs. srcdir

use the generated sources are placed into the build directory, > >> > while `make' looks for them in the source directory. > >> > >> generally, make should look for them in both places. > > Paul> Yes, and it does look in both places, but the depend

Re: builddir vs. srcdir

>>> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes: Harald> Whats about a more general case http://sources.redhat.com/automake/automake.html#Multiple-Outputs -- Alexandre Duret-Lutz

Re: builddir vs. srcdir

Hi, On Wed, Mar 09, 2005 at 11:21:35PM +0200, Paul Pogonyshev wrote: > > And I'd like to suggest that you use SUFFIXES to handle the .list > > source. Please look at the following example: > > Well, my generator is even more non-standard, since I need to pass an > additional command-line paramet

Re: builddir vs. srcdir

* Harald Dunkel wrote on Thu, Mar 10, 2005 at 09:27:34AM CET: > Stepan Kasal wrote: > >On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: > > > >>foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > >>$(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c

Re: builddir vs. srcdir

Stepan Kasal wrote: Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. You can solve the

Re: builddir vs. srcdir

ectory, >> > while `make' looks for them in the source directory. >> >> generally, make should look for them in both places. Paul> Yes, and it does look in both places, but the dependencies make `foo.o' Paul> depend on `$(srcdir)/foo.c', This could happ

Re: builddir vs. srcdir

hem in both places. Yes, and it does look in both places, but the dependencies make `foo.o' depend on `$(srcdir)/foo.c', so `make' tells it has no rule to build the latter. How do I make dependencies tell `foo.o' depends on `$(builddir)/foo.c' instead

Re: builddir vs. srcdir

al problems: > BUILT_SOURCES = \ > foo.c \ > foo.h You probably need only the foo.h file here. > foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) > $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ > || (rm -f foo.c foo.h ; exit 1) This rule

builddir vs. srcdir

this: noinst_LIBRARIES = libfoo.a BUILT_SOURCES = \ foo.c \ \ foo.h PARSE_LIST = ./parse-list$(EXEEXT) foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ;

Re: $srcdir

Clinton Roy wrote: > > "Dr. David Kirkby" <[EMAIL PROTECTED]> writes: > > > $srcdir, which I assumed refereed to the directory 'src' below the top > > directory of a package, but seems to be undefined when I try to use > > it. Putting 

Re: $srcdir

Raja R Harinath wrote: > That's too heavy-handed for tests. The idiom for tests is to use > > TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir) > > This is assuming the test scripts are listed in check_TESTS. Thanks, that does indeed work okay. -- Dr.

Re: $srcdir

t; foo rules, and include lines > like: > > [EMAIL PROTECTED]@ > > in them. > > Either that, or AC_OUTPUT a vbls.conf.in -> vbls.conf file which does this > and "source" this file in from your scripts. That's too heavy-handed for tests. The idiom for tests

Re: $srcdir

> But if I echo either $top_srcdir or $top_builddir, in the file > tests/foo.test, they are both null, so I can't seem to find a way of > referring to any files. AC_OUTPUT your test scripts using foo.in -> foo rules, and include lines like: [EMAIL PROTECTED]@ in them. Either that, or AC_OUTPU

Re: $srcdir

Philip Willoughby wrote: > $srcdir refers to the directory containing the input Makefile the Makefile > you're looking at it from was generated from. Let me try explaining that > again > > If you have the following structure: > > . > ./Makefile.in > ./src/

Re: $srcdir

Today, Dr. David Kirkby wrote: >I'm sorry I don't really know if this is an automake issue or an >autoconf one, so please excuse the posting to both groups. I'm >confused just how to best refer to files and in particular the use of >$srcdir, which I assumed refereed t

$srcdir

I'm sorry I don't really know if this is an automake issue or an autoconf one, so please excuse the posting to both groups. I'm confused just how to best refer to files and in particular the use of $srcdir, which I assumed refereed to the directory 'src' below the top di

Re: `make dist' with srcdir != builddir

>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> Some weeks ago Bruno Haible reported (in private mail) that adl> running `make dist' with srcdir != builddir could produce adl> distributions which are not up-to-date, especiall

Re: `make dist' with srcdir != builddir

Tom> I think what we want is for the positioning of the .c file not to Tom> matter for the developer, but for the file to end up in the Tom> distribution made by `make dist'. adl> The following is how I intended to fix this. I'm not sure adl> it's what you want. Anyway the patch below won't app

Re: `make dist' with srcdir != builddir

>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: [...] Tom> I think what we want is for the positioning of the .c file not to Tom> matter for the developer, but for the file to end up in the Tom> distribution made by `make dist'. The following is how I intended to fix this. I'm not sure

Re: `make dist' with srcdir != builddir

>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: adl> This can be easily fixed by changing the distdir code to look for adl> files in the builddir first and failling back to look in the adl> srcdir if needed. But maybe this is not the right

`make dist' with srcdir != builddir

Some weeks ago Bruno Haible reported (in private mail) that running `make dist' with srcdir != builddir could produce distributions which are not up-to-date, especially if you have generated files like bison parsers: $builddir/parser.c would be updated whenever $srcdir/parser.y is changed bu

Re: avoiding target $(srcdir)/Makefile.in

On Thu, Oct 05, 2000 at 12:42:06PM -0600, Tom Tromey darkened my spool with the following: > >>>>> "john" == john heasley <[EMAIL PROTECTED]> writes: > > john> is there a macro or option to automake to ommit the target > john> for $(srcdir)/Mak

Re: avoiding target $(srcdir)/Makefile.in

>>>>> "john" == john heasley <[EMAIL PROTECTED]> writes: john> is there a macro or option to automake to ommit the target john> for $(srcdir)/Makefile.in, such that it is not necessary to john> include Makefile.am and configure.in in a distribution? FYI,

Re: avoiding target $(srcdir)/Makefile.in

Hello, John! > > The last person who asked about this alleged that there will be problems > > on systems lacking Automake, but couldn't give a real example. I meant, that person expected problems if Makefile.am are included. > if these targets are in the Makefile.in, but i do not include > aclo

Re: avoiding target $(srcdir)/Makefile.in

the >following: > > Hello, John! > > > > > is there a macro or option to automake to ommit the target > > > for $(srcdir)/Makefile.in, such that it is not necessary to > > > include Makefile.am and configure.in in a distribution? > > > > It alrea

Re: avoiding target $(srcdir)/Makefile.in

On Mon, Oct 02, 2000 at 05:02:46AM -0400, Pavel Roskin darkened my spool with the following: > Hello, John! > > > is there a macro or option to automake to ommit the target > > for $(srcdir)/Makefile.in, such that it is not necessary to > > include Makefile.am and config

Re: avoiding target $(srcdir)/Makefile.in

Hello, John! > is there a macro or option to automake to ommit the target > for $(srcdir)/Makefile.in, such that it is not necessary to > include Makefile.am and configure.in in a distribution? It already becomes a FAQ. Why do you need this? The last person who asked about this all

avoiding target $(srcdir)/Makefile.in

is there a macro or option to automake to ommit the target for $(srcdir)/Makefile.in, such that it is not necessary to include Makefile.am and configure.in in a distribution? i tried including an empty target in Makefile.am. it looks as if it is created in the perl code and there dont appear to

Re: tags and config.in when srcdir!=builddir

>>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: Kevin> Using a recent cvs automake, I tried "make TAGS" in a separate Kevin> object directory, but the etags command got config.in without a Kevin> $(srcdir) path. Perhaps the @CONFIG@

tags and config.in when srcdir!=builddir

Using a recent cvs automake, I tried "make TAGS" in a separate object directory, but the etags command got config.in without a $(srcdir) path. Perhaps the @CONFIG@ in tags.am should be in the list that gets uniquified and checked for needing $(srcdir). The same might apply to $(LISP)

Re: Absolute srcdir

Lars J. Aas writes: > BTW, is anyone cataloguing these kinds of bourne shell bugs/anomalies > somewhere? Seems like something like that would be a *very* useful resource > for portable shell script programmers... > > Lars J There is a Unix shell FAQ out there, but the document I have here i

Re: Absolute srcdir

BTW, is anyone cataloguing these kinds of bourne shell bugs/anomalies somewhere? Seems like something like that would be a *very* useful resource for portable shell script programmers... Lars J

Re: Absolute srcdir

On Mon, Mar 27, 2000 at 02:58:44PM -0300, Alexandre Oliva wrote: : On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: : > I'm highly tempted to consider this a bash bug : : So am I. Which `bash' is that? I've just tested 2.04, and it *does* : present the bug :-( The same goes for GNU ba

Re: Absolute srcdir

> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> What about this fragment from acgeneral.m4 (~line 4407): Ralf> [[/\\$]]* | ?:[[/\\]]*) INSTALL="$ac_given_INSTALL" ;; Ralf> There, [[/\\$]]* is used instead of [[/\\]]*. For variables which can contain ${prefix} and such.

Re: Absolute srcdir

| Alexandre Oliva wrote: | > On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: | > | > > I'm highly tempted to consider this a bash bug | > | > So am I. Which `bash' is that? I've just tested 2.04, and it *does* | > present the bug :-( | | # bash --version | GNU bash, version 2.03.0(1)

Re: Absolute srcdir

Akim Demaille wrote: > Ralf Corsepius sent me this morning a detailed PR with about the same > behavior. I'm highly tempted to consider this a bash bug, unless > someone can demonstrate the usefulness of the following feature... > [..] > > I suppose we should drop the use of [] here. Pfff. W

Re: Absolute srcdir

Alexandre Oliva wrote: > On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > > > I'm highly tempted to consider this a bash bug > > So am I. Which `bash' is that? I've just tested 2.04, and it *does* > present the bug :-( # bash --version GNU bash, version 2.03.0(1)-release (i686-pc-li

Re: Absolute srcdir

--- Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > Or use `[/\\/]', which does work, even with bash 2.04. Or use `[\\/]', which also works. = --- Earnie Boyd: __Cygwin: POSIX on Windows__ Cygwin Newbies:

Re: Absolute srcdir

On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > I'm highly tempted to consider this a bash bug So am I. Which `bash' is that? I've just tested 2.04, and it *does* present the bug :-( > I suppose we should drop the use of [] here. Pfff. Or use `[/\\/]', which does work, even with

Re: Absolute srcdir

Akim Demaille writes: > Ralf Corsepius sent me this morning a detailed PR with about the same > behavior. I'm highly tempted to consider this a bash bug, unless > someone can demonstrate the usefulness of the following feature... I tend to agree. I ran your little script with /bin/sh and /bin/k

Re: Absolute srcdir

Ralf Corsepius sent me this morning a detailed PR with about the same behavior. I'm highly tempted to consider this a bash bug, unless someone can demonstrate the usefulness of the following feature... /tmp/build % cat /tmp/foo.sh nostromo 19:22 #! /bin/sh ca

Re: Absolute srcdir

I'm on something comparable in Autoconf. Don't know if it's the same, but I'll keep you informed. Akim

Absolute srcdir

pears that the testsuite gives the --srcdir argument to the configure which is an absolute path. The same problem can be observed when configure is just run with the full path: $ pwd /home/proskin/src/libtool/depdemo $ `pwd`/configure --quiet loading cache ./config.cache loading cache ./config.ca