AM_CONDITIONAL
Hi, in one of our projects I want to use the AM_CONDITIONAL macro to configure the software package. Here is the code fragment form the configure.in: my_add_modules= AC_MSG_CHECKING([for generating LakeShore Source Module]) my_build_lakeshore=no AC_ARG_WITH(lakeshore, AC_HELP_STRING([--with-lakeshore], [create LakeShore module, please read src/Modules/SoNXLakeShore/README]), [ if test $withval = yes; then my_build_lakeshore=yes AC_MSG_RESULT(yes) my_add_modules=$my_add_modules src/Modules/SoNXLakeShore else AC_MSG_RESULT(no) fi ], [AC_MSG_RESULT(no)] ) AM_CONDITIONAL(BUILD_LAKESHORE_MODULE, test $my_build_lakeshore = yes) the contents of the corresponding Makefile looks like: if BUILD_LAKESHORE_MODULE SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot else SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot endif This code works fine if I make a normal build. Also the 'make dist' works, but the 'make distcheck' doesn't work. It breaks with these messages: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden make[3]: *** [distdir] Error 1 make[3]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build/src/Modules' make[2]: *** [distdir] Error 1 make[2]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build/src' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/jkrueger/tmp/taco/frmII/nexus/openDaVE-0.1.4/=build' make: *** [distcheck] Error 2 I had a look at the Makefile and I found the following pieces of code .. .. SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot #SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ #FiNXDataSelector FiNXDimensionCutter \ #SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot .. .. DIST_SUBDIRS = . MySource MySink MyFilter SoNXFileReader SoNXLakeShore \ SoNXDataGenerator FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. The next question, is there a workaround to solve my problem? Thanks Jens -- Jens Krüger Technische Universität München ZBE FRM-II Lichtenberg-Str. 1 D-85747 Garching Tel: + 49 89 289 14 716 Fax: + 49 89 289 14 666 mailto:[EMAIL PROTECTED] http://www.frm2.tu-muenchen.de
Re: Bugs/Features in handling of continued Makefile rules
- Original Message - From: Dean Povey [EMAIL PROTECTED] Subject: Re: Bugs/Features in handling of continued Makefile rules -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Use ## Comment They get omitted from Makefile.in. I know about ##, I just thought handling # in Make rules by omitting them was a nicer then printing an error message. Ah, that makes more sense. What about moving the comment before/after the rule? That would preserve the comment (which is presumably the reason it was entered) and save the Makefile.in semantics. Rob
Re: AM_CONDITIONAL
Jens Krüger [EMAIL PROTECTED] writes: [snip] AM_CONDITIONAL(BUILD_LAKESHORE_MODULE, test $my_build_lakeshore = yes) the contents of the corresponding Makefile looks like: if BUILD_LAKESHORE_MODULE SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot else SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot endif This code works fine if I make a normal build. Also the 'make dist' works, but the 'make distcheck' doesn't work. It breaks with these messages: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? I'm guessing that the directory doesn't exist (since that's pretty much the main reason 'cd' would complain in a build tree). [snip] The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. 'make distcheck' is based on DIST_SUBDIRS since you want to test as much of your package as possible. It is a feature. The next question, is there a workaround to solve my problem? Given my guess, you should ensure that all directories and all Makefiles are created by the 'configure' scripts, even if the build will not enter those directories. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash
help with magically appearing _OBJECTS variable
Hello, this is the final fatal-ish flaw in my build scripts and I haven't determined why it's happening. I get this warning: tests/Makefile.am: tester_OBJECTS should not be defined here's the relevant Makefile.am: if USING_SDL if SDL_IMAGE noinst_PROGRAMS = tester sdl_test sdl_test_SOURCES = sdl_test.c sdl_test_LDADD = ../src/libmousetrap.la -lSDL -lSDL_image endif else noinst_PROGRAMS = tester endif tester_SOURCES = tester.c tester_LDADD = ../src/libmousetrap.la What I want to do is conditionally compile the sdl_test program if USING_SDL and SDL_IMAGE are defined by ./configure. I have the AM_CONDITIONAL statements for these two variables working already. What is a better approach? I'm currently using automake 1.4-p4, in debian unstable. I also experience the problem with p5, along with some others(libtool related, probably have to update it too if I want to use it, eh?) but I don't get the tester_OBJECTS warning with automake 1.5(but again, a whole slew of other issues). I didn't have this problem until I introduced the conditionals in the Makefile.am. Please include me on replies, I'm not subscribed to the automake list. Thank you, -b
Re: Potential bash 2.05 issues with 'set'
From: Tim Van Holder [EMAIL PROTECTED]
Date: Fri, 21 Sep 2001 18:44:43 +0200
bash's behaviour with regards to the 'set' builtin has changed in 2.05
This apparently lead to a broken config.cache when using bash 2.05
! ac_cv_path_install=${ac_cv_path_install='ginstall -c'}
--- 115
! ac_cv_path_install=${ac_cv_path_install=$'ginstall -c'}
Why is this broken? The two lines have the same behavior with Bash 2.05.
It's true that you can't parse the latter line with other shells.
So perhaps what you're saying is that, if you use Bash 2.05 to
run 'configure', you're stuck with using Bash 2.05 to do everything
else, too?
it is probably still worth mentioning in the autoconf manual's
section on portable shell programming.
Yes, that makes sense.
Re: Potential bash 2.05 issues with 'set'
Why is this broken? I was only relaying a problem someone else reported; it seemed odd to me, but without 2.05 lying around, I couldn't test it. It's true that you can't parse the latter line with other shells. So perhaps what you're saying is that, if you use Bash 2.05 to run 'configure', you're stuck with using Bash 2.05 to do everything else, too? Ah - rereading the original report, it was indeed the case that he went back to 2.04 since 2.05 was a bit flaky (he was doing test work to try and get DJGPP programs working properly on Win2K/WinXP). Mystery solved. it is probably still worth mentioning in the autoconf manual's section on portable shell programming. Yes, that makes sense. I'll whip up something tomorrow.
