RE: transport conditionals to other files (was: (no subject))

Thank you very much. The information is very helpful. I have solved the problem by using AC_SUBST. Ting > Date: Fri, 17 Sep 2010 22:07:00 +0200 > From: ralf.wildenh...@gmx.de > To: tingloves...@hotmail.com > CC: automake@gnu.org > Subject: transport conditionals to other

transport conditionals to other files (was: (no subject))

Hello Ting, * ting xie wrote on Thu, Sep 16, 2010 at 10:23:45PM CEST: > How are you? It is quite a long time since we talked last time. Yes. I'm just fine, thanks! (There are many other helpful readers on this list, by the way ...) > I got a new question about autoconf now. Suppose I have def

Re: distcheck ignores conditionals

Hi Jeff, * Daily, Jeff A wrote on Tue, Sep 14, 2010 at 07:07:55PM CEST: > if INLINE_X86COPY_NEEDED # x86 cpu among other specific conditions > if INLINE_X86COPY_OKAY # $(CC) handled GCC inline assembly okay > libarmci_la_SOURCES += src/x86copy.c > else > if INLINE_X86COPY_WITH # help from gcc > BU

distcheck ignores conditionals

YBE_PIC) -o $@ $< I originally had the above rule inside the INLINE_X86COPY_NEEDED conditional, which worked during the build but caused distcheck to complain about the missing rule. After I moved it, as seen above, distcheck will always attempt to create the assembly file regardless of the c

Re: conditionals in Makefile.am

if statement, possibly > >> negated using ‘!’. The else statement may be omitted. Conditionals may > >> be nested to any depth. You may specify an argument to else in which > >> case it must be the negation of the condition used for the current if. > >>

Re: conditionals in Makefile.am

On Wed, Jun 30, 2010 at 9:56 AM, John Calcote wrote: > On 6/30/2010 3:41 AM, Wesley Smith wrote: >>> From the automake manual: >>> >> You may only test a single variable in an if statement, possibly >> negated using ‘!’. The else statement may be omitted. Con

Re: conditionals in Makefile.am

On 6/30/2010 3:41 AM, Wesley Smith wrote: >> From the automake manual: >> > You may only test a single variable in an if statement, possibly > negated using ‘!’. The else statement may be omitted. Conditionals may > be nested to any depth. You may specify an argument to

conditionals in Makefile.am

> From the automake manual: You may only test a single variable in an if statement, possibly negated using ‘!’. The else statement may be omitted. Conditionals may be nested to any depth. You may specify an argument to else in which case it must be the negation of the condition used for

Re: Automake conditionals in autoconf

On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues wrote: > The above looks ok to me.  Since I cannot, from your description, > exactly reproduce the code that caused the warning for you, I cannot say > whether that was a problem. > > The code as above does not yet take care of adjusting SUBDIRS (an

Re: Automake conditionals in autoconf

Hello, * NightStrike wrote on Wed, Feb 24, 2010 at 06:29:04PM CET: > AC_MSG_CHECKING([whether to build the optional libraries]) > AC_ARG_WITH([libraries], > [AS_HELP_STRING([--with-libraries=ARG], > [Build the extra mingw-w64 libs, where ARG is one of libmangle, > pseh, or all])], > [], >

Automake conditionals in autoconf

I'm sending this to both lists because I don't know which one is right. I'm trying to conditionally configure and build subdirectories using Automake conditionals. I'm flipping back and forth between both manuals, so I'm guessing both apply. I have a top level co

Re: EXTRA_DIST respects Automake conditionals?

Hello Ben, * Ben Pfaff wrote on Thu, Jul 30, 2009 at 04:57:08AM CEST: > I was surprised today to discover that EXTRA_DIST respects > Automake conditionals. I think you are the first person to report this, but thinking about how generally conditionals more or less cover file creati

Re: EXTRA_DIST respects Automake conditionals?

Hi Ben, The reason this works is because of the way AM Conditionals are implemented. If a conditional is true, then all contained statements are in effect. Otherwise, all contained conditions are commented out in the resulting makefile. Regards, John On 7/29/2009 8:57 PM, Ben Pfaff wrote

EXTRA_DIST respects Automake conditionals?

I was surprised today to discover that EXTRA_DIST respects Automake conditionals. In other words, if I have the following Makefile.am: AUTOMAKE_OPTIONS = foreign EXTRA_DIST = if COND bin_PROGRAMS = foo foo_SOURCES = foo.c EXTRA_DIST += EXTRA endif and configure.ac

Re: conditionals

>>> "DM" == D M <[EMAIL PROTECTED]> writes: DM> Hello. DM> Is is perfectly legal to have following conditional in DM> Makefile.am: DM> if SOMETHING DM> install-data-local: DM> anything DM> endif Yes. -- Alexandre Duret-Lutz Shared books are happy books. http://www.bookcross

Re: conditionals

ndif > > Looks valid to me, according to > > http://sources.redhat.com/automake/automake.html#Conditionals > > However I'm a little perplexed as to why you would want to define > install-data-local. Isnt that a target automake will generate > automagically for you? >

Re: conditionals

<[EMAIL PROTECTED]>D M writes: > Is is perfectly legal to have following conditional in >Makefile.am: > >if SOMETHING >install-data-local: > anything >endif Looks valid to me, according to http://sources.redhat.com/automake/automake.html#Conditionals How

conditionals

Hello. Is is perfectly legal to have following conditional in Makefile.am: if SOMETHING install-data-local: anything endif So far it works for me be I must be sure that I'm not doing anything which is discouraged, violating some conventions or simply might not work. Tha

Re: Weird behavior with multiple conditionals in single Makefile.am

Alexandre Duret-Lutz wrote: Dalibor Topic wrote: Hi all, I'm fighting with something rather bizarre in automake 1.8.5 / 1.8d. In a subdir, my Makefile.am looks like this: if COND_KAFFE_X_AWT MAYBE_KAFFE_X_AWT = X else MAYBE_KAFFE_X_AWT = endif if COND_KAFFE_QT_AWT MAYBE_KAFFE_

Re: Weird behavior with multiple conditionals in single Makefile.am

SE@MAYBE_KAFFE_X_AWT = > @COND_CLASSPATH_GTK_AWT_TRUE@ MAYBE_CLASSPATH_GTK_AWT = [...] > which seems to have the weird effect of make *not* recursing into > MAYBE_X_AWT and MAYBE_CLASSPATH_GTK_AWT even if they are defined. My > only explanations is that MAYBE_KAFFE_QT_AWt bei

Re: Weird behavior with multiple conditionals in single Makefile.am

BDIRS, while the other MAYBE_* conditionals are forgotten. Any ideas? Do I really have to cut and paste this into one giant, exponantial if-else conditional? Mark one up for the brainded make tab-vs-spaces thing. For some reason, the MAYBE_KAFFE_QT_AWT conditional used spaces to indent the setti

Weird behavior with multiple conditionals in single Makefile.am

AYBE_* conditionals are forgotten. Any ideas? Do I really have to cut and paste this into one giant, exponantial if-else conditional? cheers, dalibor topic

Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes: Dalibor> They use make -DCHECK=1 to enable adding of special debuggin flags, Dalibor> for example, and make -DPROF=1 to add another set of flags to enable a Dalibor> build fro profiling. You can always add your own targets: debuggi

Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

On Wed, 10 Dec 2003, Dalibor Topic wrote: > > Bob Friesenhahn wrote: > > You can use Automake conditionals. These are configure-time > > conditionals rather than make-time conditionals. > > > > You could add --with-check and --with-prof options to your configure

Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

You can use Automake conditionals. These are configure-time conditionals rather than make-time conditionals. You could add --with-check and --with-prof options to your configure script which enables these conditionals. If your package preserves the capability to build outside of the source tree

Re: Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

Hi Bob, thanks for the quick reply. Bob Friesenhahn wrote: You can use Automake conditionals. These are configure-time conditionals rather than make-time conditionals. You could add --with-check and --with-prof options to your configure script which enables these conditionals. Done. But

Emulating GNU Make conditionals, or: Is there a nice way to automatically set CFLAGS when make is run?

Hi all I have a problem converting an old code base to GNU Automake, in that the developers are used to spicing up their GNU Makefiles with GNU Make conditionals, that are evaluated when make is run, in order to have some shortcut options for setting CFLAGS. They use make -DCHECK=1 to enable

Re: Conditionals in Makefile.am

: Pekka> This sort of thing is not possible now and makes it : Pekka> really ugly to use the conditionals in makefiles, imo. : Pekka> Currently only way to do this is to conditionalize the : Pekka> entire FILES variable. Alternatively it could just : Pekka> remove the

Re: Conditionals in Makefile.am

Pekka> endif Pekka> something.c Pekka> This sort of thing is not possible now and makes it Pekka> really ugly to use the conditionals in makefiles, imo. Pekka> Currently only way to do this is to conditionalize the Pekka> entire FILES variable. Alternatively it could just

Re: Conditionals in Makefile.am

>>> "Pekka" == Pekka Riikonen <[EMAIL PROTECTED]> writes: [...] Pekka> I don't think changing this would be hard (haven't Pekka> looked at code though), and it doesn't cause Pekka> compatibility problems, and would make the conditionals Pekka&

Conditionals in Makefile.am

A suggestion to conditionals in Makefiles. Conditionals inside Makefiles could be changed to replace the not-included lines with empty lines instead of commenting them with '#'. If it would just replace them with empty lines it would allow configuration like th

Re: Conditionals in Makefile.am

On Tuesday 11 June 2002 18:14, Filip Kaliński wrote: > I have AM_CONDITIONAL(ENABLE_BAR, ... ) in configure.in and I want to have > > if ENABLE_BAR > lib_LTLIBARAIES=libfoo.la > libfoo_la_LDADD=-lbaz > ... > else > noninst_LTILIBRARIES=libfoo.la > ... > endif > > in Makefile.am, but it doesn't wor

Re: Conditionals in Makefile.am

>>> "Filip" == Filip Kaliński <[EMAIL PROTECTED]> writes: Filip> I have AM_CONDITIONAL(ENABLE_BAR, ... ) in configure.in Filip> and I want to have Filip> if ENABLE_BAR Filip> lib_LTLIBARAIES=libfoo.la Filip> libfoo_la_LDADD=-lbaz Filip> ... Filip> else Filip> noninst_LTILIBRARIES=libfoo.

Conditionals in Makefile.am

I have AM_CONDITIONAL(ENABLE_BAR, ... ) in configure.in and I want to have if ENABLE_BAR lib_LTLIBARAIES=libfoo.la libfoo_la_LDADD=-lbaz ... else noninst_LTILIBRARIES=libfoo.la ... endif in Makefile.am, but it doesn't work, automake wants to define both of ..._LTLIBRARIES and screams that it is

Re: Primaries in Conditionals

Am Fre, 2002-02-22 um 03.23 schrieb Fausto Sanchez: > Hi, > > Can anyone tell me how to suppress these warning from automake. I just upgraded > to automake 1.5, and now these warnings are being displayed when running > automake. This kind of questions is going to be an FAQ ;) > diag_LDADD = @L

Re: Primaries in Conditionals

On Fri, 2002-02-22 at 03:23, Fausto Sanchez wrote: > Hi, > > Can anyone tell me how to suppress these warning from automake. I just upgraded > to automake 1.5, and now these warnings are being displayed when running > automake. > > diag_LDADD = @LDFLAGS@ -L../common_objects -ldiagcommonobj -ldi

Primaries in Conditionals

Hi, Can anyone tell me how to suppress these warning from automake. I just upgraded to automake 1.5, and now these warnings are being displayed when running automake. -- WARNINGS I GET automake: isan/

Re: unterminated conditionals

> "Johannes" == Kremp, Johannes (Extern) <[EMAIL PROTECTED]> writes: Johannes> and in my 'Makefile.am': Johannes> if HELLO Johannes> include hellofiles Johannes> bin_PROGRAMS = hello Johannes> hello_SOURCES = $(FILES) #from file 'hellofiles' Johannes> endif Tha

RE: unterminated conditionals

ude hellofiles bin_PROGRAMS = hello hello_SOURCES = $(FILES) #from file 'hellofiles' endif 'automake' told me: automake: src/Makefile.am: unterminated conditionals: @HELLO_TRUE@ johannes

Re: unterminated conditionals

> "Johannes" == Kremp, Johannes (Extern) <[EMAIL PROTECTED]> writes: What version of automake are you using? Please include version info in every bug report. Johannes> and in my 'Makefile.am': if HELLO Johannes> ... Johannes>

unterminated conditionals

#x27; told me: automake: src/Makefile.am: unterminated conditionals: @HELLO_TRUE@ it would be very nice, if vou could tell me what i can do to solve the problem. thanks johannes

Re: Bug with conditionals. [PATCH]

6,6 +126,7 @@ cond8.test \ cond9.test \ cond10.test \ +cond11.test \ condincl.test \ condincl2.test \ condlib.test \ Index: tests/cond11.test === RCS file: cond11.test diff -N cond11.test --- /dev/null Tue May 5 13:32:27 1998 +++ cond11.test Sun Jun 10 09:06:33 2001 @@ -0,0 +1,

Bug with conditionals. [PATCH]

/dev/null Tue May 5 13:32:27 1998 +++ cond11.test Tue Jun 5 18:13:54 2001 @@ -0,0 +1,41 @@ +#! /bin/sh + +# Test for bug in conditionals. From Richard Boulton. +# This checks that, if LDADD is set from a conditional variable +# and an AC_SUBST, the _DEPENDENCIES variable is set correctl

Re: PATCH: subdirs and conditionals

On Sat, May 05, 2001 at 03:18:56PM -0600, Tom Tromey wrote: > How do you define SUBDIRS? By condtionally defining a set of variables, and then defining SUBDIRS in terms of each of these conditional variables. I attach the Makefile.am in question, for reference. > Please send a ChangeLog entry wi

Re: problem with conditionals and \ separator in SOURCES

> "Lorenzo" == Lorenzo Bettini <[EMAIL PROTECTED]> writes: >> Automake 1.4 didn't try to deal with DOS-style line endings correctly. Lorenzo> You're right: line endings are to blame... the funny thing is Lorenzo> that I got the sources from a Linux CVS server, and the Lorenzo> uncorrect line

Re: PATCH: subdirs and conditionals

>>>>> "Richard" == Richard Boulton <[EMAIL PROTECTED]> writes: Richard> The gstreamer project, however, has a Makefile.am with Richard> conditionals for each of a set of conditions dictating which Richard> SUBDIRS are to be built. The file currentl

PATCH: subdirs and conditionals

omake version 1.4, in case that is of any use. === In current automake, if a variable is defined in terms of N conditionally defined variables, an array of possible combinations of conditional values is generated. This array is, of course, of size 2^N, which implies that only small numbers of conditi

PATCH: subdirs and conditionals

In current automake, if a variable is defined in terms of N conditionally defined variables, an array of possible combinations of conditional values is generated. This array is, of course, of size 2^N, which implies that only small numbers of conditionals can effectively be used together. The

Re: problem with conditionals and \ separator in SOURCES

Tim Van Holder wrote: > > > You're right: line endings are to blame... the funny thing is that I got > > the sources from a Linux CVS server, and the uncorrect line endings seem > > to have been added during the dowloading... (actually I used WinCVS, so > > this is quite likely). > > If you're u

RE: problem with conditionals and \ separator in SOURCES

> You're right: line endings are to blame... the funny thing is that I got > the sources from a Linux CVS server, and the uncorrect line endings seem > to have been added during the dowloading... (actually I used WinCVS, so > this is quite likely). If you're using WinCVS and working with Unix/Lin

Re: problem with conditionals and \ separator in SOURCES

Tom Tromey wrote: > > > "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: > > >> Am I doing something wrong? > >> Notice that this problem only takes place with cygwin > > Tim> Might be an EOL issue; sed is notorious for not recognizing a trailing \ > Tim> in a DOS text file (it sees \ +

Re: problem with conditionals and \ separator in SOURCES

> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: >> Am I doing something wrong? >> Notice that this problem only takes place with cygwin Tim> Might be an EOL issue; sed is notorious for not recognizing a trailing \ Tim> in a DOS text file (it sees \ + CR + NL). Tim> Try converting the f

RE: problem with conditionals and \ separator in SOURCES

> cmdline.c \ > main.cc errors.cc stringtable.cc tables.cc nodevis.cc \ > > and the problem seems to be that \ in myprog_SOURCES is not recognized! > > Am I doing something wrong? > Notice that this problem only takes place with cygwin > Might be an EOL issue;

problem with conditionals and \ separator in SOURCES

Hi In configure.in I have these lines AC_PATH_PROGS(GENGETOPT, gengetopt) AM_CONDITIONAL(NO_GENGETOPT, test -z "$ac_cv_path_GENGETOPT" ) and in src/Makefile I have SUFFIXES = .ggo if NO_GENGETOPT .ggo.c: touch $@ else .ggo.c: $(GENGETOPT) --input $< --unamed-opts endif

FYI: 93-robert-fix.patch (Was: Conditionals in CVS Automake)

| [EMAIL PROTECTED] wrote: | > | > I think I have it. It's a very stupid typo :( | > | > | > | >patchName: patch | > Type: Plain Text (text/plain) | | Fixed. :) Thanks Akim! Thanks for your help! I'm a

Re: Conditionals in CVS Automake

: "Robert Boehne" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 27, 2001 12:45 PM Subject: Re: Conditionals in CVS Automake > >>>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: > > Robert>

Re: Fixed? (Was: Conditionals in CVS Automake)

[EMAIL PROTECTED] wrote: > > I think I have it. It's a very stupid typo :( > > > >patchName: patch > Type: Plain Text (text/plain) Fixed. :) Thanks Akim! Robert -- Robert Boehne Software En

Re: Help with CVS (Was: Conditionals in CVS Automake)

- Original Message - From: <[EMAIL PROTECTED]> To: "Robert Boehne" <[EMAIL PROTECTED]> Cc: "Akim Demaille" <[EMAIL PROTECTED]>; "Lars J. Aas" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, March 28, 2001 7:27 AM S

Fixed? (Was: Conditionals in CVS Automake)

I think I have it. It's a very stupid typo :( --- /home/akim/src/am/program.amThu Mar 8 20:36:38 2001 +++ program.am Tue Mar 27 23:34:03 2001 @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright 1994, 1995, 1996, 1997 Free Software Foundation, Inc. +## Cop

Re: Help with CVS (Was: Conditionals in CVS Automake)

On Tue, Mar 27, 2001 at 11:11:42PM +0200, [EMAIL PROTECTED] wrote: > > It's between revision 0.119 and 0.120, diffs attached. I'm looking for > the problem. Here are the changes it introduces. At the bottom you can see what went wrong. There is something in the PROGRAMS handling I broke :(

Re: Help with CVS (Was: Conditionals in CVS Automake)

On Tue, Mar 27, 2001 at 10:52:52PM +0200, [EMAIL PROTECTED] wrote: > > I'm home currently, which means... I have my prcs handy :) Starting to > track down more precisely... It's between revision 0.119 and 0.120, diffs attached. I'm looking for the problem. Index: 0.119/ChangeLog --- 0.119/Ch

Re: Help with CVS (Was: Conditionals in CVS Automake)

On Tue, Mar 27, 2001 at 01:41:51PM -0600, Robert Boehne wrote: > Akim: > > I think the breakage was introduced on March 5. I wasn't > able to narrow it down to any specific change though. > None of them seemed to me like they were candidates. My script seems to agree with you :) Getting 19 day

RE: Help with CVS (Was: Conditionals in CVS Automake)

> Thanks, but I was really asking the question for the whole *project*. > With PRCS I can talk about revision n - 1 of the *project*, i.e., the > full set of the files. According to private messages with Lars > (Hecking :), you need to tag to be able to do that. So I dropped this > idea and I'm

Re: Help with CVS (Was: Conditionals in CVS Automake)

On Tue, Mar 27, 2001 at 09:06:38PM +0200, Akim Demaille wrote: : According to private messages with Lars (Hecking :), you need to tag : to be able to do that. Hehe, we're now three (late entry by Lars Stavholm), so you better be specific in the times to come. You can emphasize me by using Coffee

Re: Help with CVS (Was: Conditionals in CVS Automake)

Akim: I think the breakage was introduced on March 5. I wasn't able to narrow it down to any specific change though. None of them seemed to me like they were candidates. Robert Akim Demaille wrote: > > > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: > > Lars> On Tue, Mar 27, 2001 at 0

Re: Help with CVS (Was: Conditionals in CVS Automake)

> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> On Tue, Mar 27, 2001 at 08:26:59PM +0200, Akim Demaille wrote: : Lars> Could someone teach me how to go backward with CVS and pull out Lars> : revision n-1? I'm quite lost with this issue, and I'd like to Lars> use CVS : to have at lea

Re: Help with CVS (Was: Conditionals in CVS Automake)

On Tue, Mar 27, 2001 at 08:26:59PM +0200, Akim Demaille wrote: : Could someone teach me how to go backward with CVS and pull out : revision n-1? I'm quite lost with this issue, and I'd like to use CVS : to have at least an idea of _when_ it started to fail. I know how to : do that with PRCS, but

Help with CVS (Was: Conditionals in CVS Automake)

Could someone teach me how to go backward with CVS and pull out revision n-1? I'm quite lost with this issue, and I'd like to use CVS to have at least an idea of _when_ it started to fail. I know how to do that with PRCS, but have no idea about CVS. Thanks!

Re: Conditionals in CVS Automake

> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: Robert> @BINARY_HELLDL_TRUE@am_helldl_OBJECTS = dlmain.$(OBJEXT) Robert> helldl_OBJECTS = $(am_helldl_OBJECTS) Robert> If @BINARY_HELLDL_TRUE@ is expanded to "#" then there is no Robert> definition for $(am_helldl_OBJECTS), but it is us

Re: Conditionals in CVS Automake

Akim: Ok, I hand-edited the Makefile.in's to add -c to the rule that makes libtool *.lo objects, then reconfigured. But the original problem exists in your patched version. I'm looking into the differences between the Makefile.in's in libtool's demo directory and I've noticed that the CVS version

Re: Conditionals in CVS Automake

Akim Demaille wrote: > > > "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: > > Robert> Hello all! I've found a problem with conditional compilation > Robert> in the CVS version of Automake that was introduced some time > Robert> since March 4. Multi-language-branch libtool fails 16 t

Re: Conditionals in CVS Automake

> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: Robert> Hello all! I've found a problem with conditional compilation Robert> in the CVS version of Automake that was introduced some time Robert> since March 4. Multi-language-branch libtool fails 16 test Robert> cases because the Make

Conditionals in CVS Automake

Hello all! I've found a problem with conditional compilation in the CVS version of Automake that was introduced some time since March 4. Multi-language-branch libtool fails 16 test cases because the Makefile lacks the rules that it needs, to build a target, they are commented out. Could someone

Re: Conditionals in Makefile

> "Akim" == akim <[EMAIL PROTECTED]> writes: Akim> i understood my question was stupid: the order does not matter, Akim> because if it's a rule, then it amkes no sense (hence is Akim> forbidden) to have two equivalent conditions (actually one being Akim> provalbe by the other is enough) or i

Re: Conditionals in Makefile

>>>>> "Akim" == akim <[EMAIL PROTECTED]> writes: Akim> The question can be asked as ``how should be output conditionals Akim> in Makfiles: the order does not matter, hence alphabetical is Akim> fine, or order matters''. If you mean the output

Re: Conditionals in Makefile

> If the order does not matter, then sorting it can simplify a lot from > the code: simplify sort the conditions, that makes a uniq means to > designates them (conditional_same makes no sense, use eq, etc.). > The backdraw is that the user cannot see in the Makefile something > which is related to

Conditionals in Makefile

There is a choice to make wrt conditionals, and I'd like to have your opinion as both choices can be defended with sensible arguments. The question can be asked as ``how should be output conditionals in Makfiles: the order does not matter, hence alphabetical is fine, or order matters&#

Re: 43-conditionals-as-hashes.patch

Tom Tromey <[EMAIL PROTECTED]> writes: > Akim> Ideally I'd say we need objects for variables, and have a > Akim> uniformized handling of conditionalized/unconditinal variables. > > This patch needed a lot less defense than you posted -- the only > reason condi

Re: 43-conditionals-as-hashes.patch

>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Ideally I'd say we need objects for variables, and have a Akim> uniformized handling of conditionalized/unconditinal variables. This patch needed a lot less defense than you posted -- the

Re: 44-conditionals-cleanup.patch

> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&check_ambiguous_conditional, &read_main_am_file): Akim> Use a uniform naming scheme. Akim> ("e_cond_val, &unquote_cond_val): Delete, dead code. Akim> (&read_am_file): Fix conditioned definition of backslash co

Re: 42-conditionals-true-when.patch

> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&conditional_true_when): Modernize, simplify. Akim> Warning: `$comp' is now private (my), while it used to be Akim> `inherited' from a `local' elsewhere in the code. AFAICT it was Akim> wrong, but some dirty s

43-conditionals-as-hashes.patch

ndling of conditionalized/unconditinal variables. This patch leaves scories of previously needed subs, which another patch will clean up. As Jacques Brel, the great francophone Belgian singer, would say, ``Too much c'est too much''. Index: ChangeLog from Akim Demaille <[EM

44-conditionals-cleanup.patch

Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> * automake.in (&check_ambiguous_conditional, &read_main_am_file): Use a uniform naming scheme. ("e_cond_val, &unquote_cond_val): Delete, dead code. (&read_am_file): Fix conditioned definition of backslash con

42-conditionals-true-when.patch

doesn't add an extra \n at the end. sub do_one_merge_target @@ -3754,6 +3756,7 @@ sub do_one_merge_target &depend ('.PHONY', $name . '-am', $name); } + # Handle check merge target specially. sub do_check_merge_target { @@ -5291,27 +5294,27 @@ sub target_

Re: Gnu make conditionals in Makefile.am

On Sep 11, 2000, Ralf Reißing <[EMAIL PROTECTED]> wrote: > Unfortunately, automake thinks these conditionals are automake > conditionals ("endif without if") and does not process the file. > Is there a way of "masking" conditionals from automake so it > si

Gnu make conditionals in Makefile.am

I am trying to do the following: Depending on the target platform (available in $target from AC_CANONICAL_SYSTEM in configure.in) a variable OS_FLAGS in the Makefile should be set to specifix values, e.g. on Linux: OS_FLAGS = -DUNIX -DLINUX I tried to add gnumake conditionals for this to

Re: Automake conditionals

(Sorry for the late follow-up on this. I've been moving and changing jobs.) On 15 Jun 2000, Alexandre Oliva wrote: > On Jun 14, 2000, "Braden N. McDaniel" <[EMAIL PROTECTED]> wrote: > > > automake: src/Makefile.am: `libjs.la' is already going to be installed in > > `noinst' > > This is a limit

Re: Automake conditionals

Alexandre> In particular, in the case of installing the library, you Alexandre> must add the -rpath switch to LDFLAGS_LIBJS. I believe Alexandre> that's the main reason why automake doesn't support Alexandre> conditional installation of ltlibraries. Yes, that's right. Is there something we can d

Re: Automake conditionals

On Wednesday, June 14, 2000, "Braden N. McDaniel" <[EMAIL PROTECTED]> wrote: > > 1 EXTRA_LTLIBRARIES = libjs.la > 2 if JS_INSTALL > 3 lib_LTLIBRARIES = libjs.la > 4 else > 5 noinst_LTLIBRARIES = libjs.la > 6 endif You might also try something like this (not tested): if JS_INSTALL INSTALL_LI

Re: Automake conditionals

On Jun 14, 2000, "Braden N. McDaniel" <[EMAIL PROTECTED]> wrote: > automake: src/Makefile.am: `libjs.la' is already going to be installed in > `noinst' This is a limitation of automake. The solution I've been using is like this: EXTRA_LTLIBRARIES = libjs.la lib_LTLIBRARIES = @lib_LIBJS@ noinst

Re: Automake conditionals

On Wed, 14 Jun 2000, Michael Bletzinger wrote: > I don't think you need line 1. Okay... That may be, but as I said, getting rid of it still yields one set of those errors I mentioned. -- Braden N. McDaniel [EMAIL PROTECTED]

Re: Automake conditionals

per library. I am hoping to > consolidate these substitutions into one or two automake conditionals. > > I have an automake conditional that looks like this (lines numbered for > reference): > > 1 EXTRA_LTLIBRARIES = libjs.la > 2 if JS_INSTALL > 3 lib_LTLIBRARIES = libjs.la &

Automake conditionals

I have an automake script which, depending on the value of some substitutions defined in configure, allows a library to be built either as something that will be installed or as a helper library. I am hoping to consolidate these substitutions into one or two automake conditionals. I have an