Re: mingw compiler on cygwin, and path issues

Hello Jan, * Jan Engelhardt wrote on Fri, Apr 10, 2009 at 10:23:53PM CEST: > Given: > > AM_LDFLAGS = -L../subproject > foo_LDADD = -lsub For in-tree libraries always use relative paths to the .la file: foo_LDADD = ../subproject/libsub.la you can omit the AM_LDFLAGS. Does the issue remain wit

Re: mingw compiler on cygwin, and path issues

On Friday 2009-04-10 22:19, Jan Engelhardt wrote: > >AM_CFLAGS = -I${abs_top_builddir}/subproject >AM_LDFLAGS = -L${abs_top_builddir}/subproject > >This gets expanded into -I/home/User/project/subproject, but the mingw >compiler of course tries to search in C:\home\user\project\subproject >instea

mingw compiler on cygwin, and path issues

Hi, I am currently using automake in a Windows-related project; there is a (pure) mingw compiler in c:\mingw, and cygwin is installed in c:\cygwin. Now I noticed that Makefile.in, as generated by automake, has a CYGPATH_W variable which is `echo` on Unices, and `cygpath -w` on Cygwin. The prob

Re: aclocal problems

By the way, you may be interested in seeing how I was able to use m4_define and still get aclocal to use my file for gnulib's AC_DEFUN_ONCE replacement (coupled with an AC_REQUIRE([gl_00GNULIB]) in gnulib-common.m4): http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/00gnulib.m4 http://git.savan

Re: aclocal problems

* Eric Blake wrote on Fri, Apr 10, 2009 at 02:12:10PM CEST: > According to Ralf Wildenhues on 4/10/2009 12:32 AM: > > > > Good point. Public third-party macros should be AC_DEFUNed for this > > reason. OK to apply?

Re: aclocal problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: > > > Hi Eric, John, > > * John Calcote wrote on Sat, Apr 04, 2009 at 06:55:46AM CEST: >> On 4/3/2009 5:31 PM, Ralf W

Re: aclocal problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 4/10/2009 12:32 AM: > > >> I'd call it a documentation bug at this point. (Eric - comments?) Sorry for missing this thread; I tend not to