Re: Multiple lex scanners? How?
On Mon, Jan 15, 2007 at 04:52:37PM -0700, Bob Proulx wrote: > Multiple flex generated scanners are giving me trouble with duplicate > symbols. I am using automake-1.10. > > What is the best practice for organizing a program that includes > multiple lex generated scanners? > > I am using the recommended practice of using defines to rename all of > the yacc/lex symbols as described in the automake manual > (e.g. "#define yylex c_lex", "#define yyerror c_error", etc.) for the > yacc generated parser. The problem I encounter is that yyin is hard > to get redefined. Flex outputs a definition for it before outputing > my define for it in the top of the scan.l file. > > Basically what I have looks like this: > > myprog_SOURCES = parse.y scan.l > BUILT_SOURCES = parse.c parse.h scan.c > AM_YFLAGS = -d > > That is all well and good but then yyin is a global symbol defined by > the flex generated scanner. This appears before I can redefine it > inside the source. > > I guess I can add an AM_CPPFLAGS=-Dyyin=myprogin and list out all of > the symbols to redefine there. But that fails to work if I have two > flex generated scanners in the same directory. I would rather find a > more general solution. > > If I add an option to flex to rename the symbols like this then the > scanner flex generates renames the symbols for me. > > AM_LFLAGS = -l -Pmyprog > > But in this case ylwrap fails because -P also renames the output file > to lex.myprog.c and ylwrap fails to find the produced file. And it > has the same problem of failing if there are two flex generated > scanners in the same directory. > > I am about ready to write a custom rule to sed the generated file. I > am sure that will work but I must be missing something obvious since > this is a common enough problem that there must be a standard > solution that I am missing. I have a program that use 17 flex scanners (and 17 grammatical analysers) to detect/parse biological sequence and alignement formats. I encountered the same problem ... and made the following constructs that did the trick (at least for me). AUTOMAKE_OPTIONS = subdir-objects AM_YFLAGS = -d -p `basename $* | sed 's,y$$,,'` AM_LFLAGS = -s -P`basename $* | sed 's,l$$,,'` -olex.yy.c [...] CLU_SRC = align/clustal.c align/clustaly.y align/clustall.l CLU_HDR = align/clustal.h EMB_SRC = sequence/embl.c sequence/embly.y sequence/embll.l EMB_HDR = sequence/embl.h FAS_SRC = sequence/fasta.c sequence/fastay.y sequence/fastal.l FAS_HDR = sequence/fasta.h [...] Hope this helps, Regards. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: adding subdirectories
On Mon, Mar 07, 2005 at 02:07:41PM +0100, [EMAIL PROTECTED] wrote: > Hello, > > I build my project in a single directory using automake, like this: > > AUTOMAKE_OPTIONS = dejagnu > bin_PROGRAMS = zzz > noinst_PROGRAMS = test1 test2 test3 > noinst_LTLIBRARIES = libzzz.la > zzz_SOURCES = zzz.c > libzzz_la_SOURCES = a/a.c b/b.c > AM_CFLAGS = -g -Wall -std=c99 -I$(top_srcdir)/include @ZZZ_CFLAGS@ > -DSYSCONFDIR=\"@[EMAIL PROTECTED]" > zzz_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > test1_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > test2_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > test3_LDADD = @ZZZ_LIBS@ $(top_builddir)/libzzz.la > > Now I want to separate the production targets from the regression tests. > I moved the noinst_PROGRAMS to testsuite/Makefile.am and > AC_SUBST(AM_CFLAGS) in configure.ac. However, now I've got two problems: [...] > 2. More importantly, I can't build the project any more: make >immediately dives into testsuite/, files under which require >libzzz.la, which is going to be built later. If I "make libzzz.la >all", everything works fine. Use `SUBDIRS = . testsuite' in your Makefile.am, this will force the directory processing order. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
installation permissions overwrite with nobase_ prefix ?
Hi,
I'm trying to setup custom installation permissions for a project
where a group will install/update some packages, and then need non
standard permissions on files (664) and directories (775) ...
For most of them, it works pretty well by setting some `INSTALL_*'
variables in config.site file:
INSTALL_DATA="\${INSTALL} -m 664"
INSTALL_PROGRAM="\${INSTALL} -m 775"
INSTALL_SCRIPT="\${INSTALL} -m 775"
but problems arise when projects use the `nobase_' prefix. In that
case, Automake create some new variables `install_sh_*' which are not
substitued at configure time.
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
It would be great to be able to use the same permissions in both
cases.
Did i missed something, or there is no easy way yet ?
Thanks in advance,
Regards.
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
Re: automake 1.8.3: Tru64: fix for depcomp
On Mon, May 31, 2004 at 11:44:49PM +0200, Alexandre Duret-Lutz wrote: > >>> "Nicolas" == Nicolas Joly <[EMAIL PROTECTED]> writes: > > [...] > > Nicolas> I just made some testing with one of my projects with automake 1.8.4 / > Nicolas> libtool 1.5.6, and noticed some remaining problems about libtool and > Nicolas> Tru64 dependency mode. [...] > Nicolas> I that case, shouldn't it be better to use for tmpdepfile2 : > > Nicolas> "$dir$base.o.d" instead of "$dir.libs/$base.o.d" > > Nicolas> NB: "$dir.libs/$base.o.d" are automatically cleaned > Nicolas> with `make distclean', with the `.libs' directory > Nicolas> removal. > > Thanks for the testing, and sorry it took me so long to answer. > I missed the mail. > > I'm checking this in. > > 2004-05-31 Alexandre Duret-Lutz <[EMAIL PROTECTED]> > > * lib/depcomp (tru64) [libtool]: Use $dir$base.o.d instead > of $dir.libs/$base.o.d. Libtool 1.5 causes both to be output, > and we will clean the second automatically during distclean. > Using the latter and leaving the former as we did before cause > "files left in build directory" failures during distcheck. > Suggested by Nicolas Joly. Great! Most files are now gone. The only one remaining is `so_location', but it seems that it was dropped by `configure' script. I need to investigate a little more about this one ... Thanks a lot. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: automake 1.8.3: Tru64: fix for depcomp
On Sat, Apr 24, 2004 at 11:20:59AM +0200, Alexandre Duret-Lutz wrote: > >>> "Burgers" == Burgers A R <[EMAIL PROTECTED]> writes: > > Burgers> In order to get the dependencies for a LTLIBRARY right for Tru64's > Burgers> native cc C-compiler, I had to apply the following patch to > Burgers> automake's depcomp script. cc -MD outputs the dependencies in the > Burgers> .o.d file, not in the .lo.d file. > > Burgers> I am using automake 1.8.3, autoconf 2.59, > Burgers> libtool (ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)) > > Thanks, I'm installing the following patch on HEAD and > branch-1-8. It would be nice to know the difference between > your setup and Nicolas's. > > 2004-04-24 Alexandre Duret-Lutz <[EMAIL PROTECTED]> > > * lib/depcomp (tru64) [libtool]: Nicolas Joly reported on > 2002-06-12 that dependencies were output in $dir.libs/$base.lo.d. > Teun Burgers reported on 2004-03-30 they were in $dir.libs/$base.o.d. > Try both. I just made some testing with one of my projects with automake 1.8.4 / libtool 1.5.6, and noticed some remaining problems about libtool and Tru64 dependency mode. source='sequence.c' object='sequence.lo' libtool=yes depfile='.deps/sequence.Plo' tmpdepfile='.deps/sequence.TPlo' depmode=tru64 /bin/ksh ../depcomp /bin/ksh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o sequence.lo sequence.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -MD sequence.c -DPIC -o .libs/sequence.o cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -MD sequence.c -o sequence.o >/dev/null 2>&1 With libtool 1.5 and Tru64 C compiler, 2 separate objects are now generated. And, as a side effect, two separate `.d' dependencies files are made : `sequence.o.d' and `.libs/sequence.o.d'. Actually, the second one is processed to make the final `.deps/sequence.Plo' file. But the first one remains unused, and seems forgotten here ... This breaks `gmake distcheck' target, which complains about `files left in build directory after distclean'. I that case, shouldn't it be better to use for tmpdepfile2 : "$dir$base.o.d" instead of "$dir.libs/$base.o.d" NB: "$dir.libs/$base.o.d" are automatically cleaned with `make distclean', with the `.libs' directory removal. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: automake 1.8.3: Tru64: fix for depcomp
On Thu, Apr 29, 2004 at 12:37:56AM -0500, Albert Chin wrote: > On Sat, Apr 24, 2004 at 12:22:30PM +0200, Nicolas Joly wrote: > > With Tru64 cc compiler, shared objects can also be used to make a > > static library. This mecanism is used in libtool 1.4 series to handle > > both shared and static libraries. But, this exception was removed for > > libtool 1.5 which now generates 2 separate objects (PIC vs. non PIC) > > for the 2 libraries (shared vs. static); like other compilers. > > Are you sure? I thought all object files on Tru64 UNIX were PIC? Agreed, both objects are PIC (default on Tru64). The main concern was that now 2 separate objects are created (one with `-DPIC' and the other without) : /bin/ksh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I. -I. -g -c ltdl.c -DPIC -o .libs/ltdl.o cc -DHAVE_CONFIG_H -I. -I. -I. -g -c ltdl.c -o ltdl.o >/dev/null 2>&1 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: automake 1.8.3: Tru64: fix for depcomp
On Sat, Apr 24, 2004 at 11:20:59AM +0200, Alexandre Duret-Lutz wrote: > >>> "Burgers" == Burgers A R <[EMAIL PROTECTED]> writes: > > Burgers> In order to get the dependencies for a LTLIBRARY right for Tru64's > Burgers> native cc C-compiler, I had to apply the following patch to > Burgers> automake's depcomp script. cc -MD outputs the dependencies in the > Burgers> .o.d file, not in the .lo.d file. > > Burgers> I am using automake 1.8.3, autoconf 2.59, > Burgers> libtool (ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58)) > > Thanks, I'm installing the following patch on HEAD and > branch-1-8. It would be nice to know the difference between > your setup and Nicolas's. I think, if remember correctly, that there is a behaviour change between libtool 1.4 and 1.5 series for the Tru64 compiler. With Tru64 cc compiler, shared objects can also be used to make a static library. This mecanism is used in libtool 1.4 series to handle both shared and static libraries. But, this exception was removed for libtool 1.5 which now generates 2 separate objects (PIC vs. non PIC) for the 2 libraries (shared vs. static); like other compilers. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: LONG: Limitations of Make (Portable Shell Programming chapter of Autoconf)
On Sun, Mar 24, 2002 at 07:16:08PM +0100, Alexandre Duret-Lutz wrote: > [...] > `VPATH' > There is no `VPATH' support specified in POSIX. Many Makes have a > form of `VPATH' support, but its implementation is not coherent > amongst Makes. > > Maybe the best suggestion to do to people who needs the `VPATH' > feature is to chose a Make implementation an stick to it. Since > the resulting `Makefile's are not portable anyway, better chose a > portable Make (hint, hint). > > Here are a couple of known issues with some `VPATH' > implementations. [...] > OSF/Tru64 make creates prerequisite directories magically > When a prerequisite is a sub-directory of `VPATH', Tru64 Make > will create it in the current directory. > >% cat Makefile >VPATH = .. >all : foo/bar >% make -p foo/bar build mkdir >% cd build >% make >mkdir foo >mkdir foo/bar > > This can yield unexpected results if a rule uses a manual > `VPATH' search as presented before. > >VPATH = .. >all : foo/bar >command `test -d foo/bar || echo ../`foo/bar > > The above `command' will be run on the empty `foo/bar' > directory created in the current directory. -- Nicolas Joly Biological Software and Databanks. Pasteur Institute, Paris.
