[ovs-discuss] Enabling user defined preprocessing definitions during compilation of OVS 1.2.2

Ramana Reddy gtvrreddy at gmail.com
Sat Nov 12 15:56:49 UTC 2011


Hi Ben,
That is fine. Even I also understood the AM_CONDITIONAL macros must be
defined in configure.ac , and I verified in OVS code how HAVE_NETLINK macro
defined in OVS-1.1.1, and the configure.ac file does not contain any
AM_CONDITIONAL Macros, and all Macros used in OVS are defined in
m4/openvswitch.m4 file.
That's why I followed similar procedure. Now, my question is How OVS differ
from the normal procedure and
how this can be done in OVS.

Thanks,
Ramana Reddy.

On Sat, Nov 12, 2011 at 9:02 PM, Ben Pfaff <blp at nicira.com> wrote:

> From the Automake manual:
>
> File: automake-1.11.info,  Node: Usage of Conditionals,  Next: Limits of
> Conditionals,  Up: Conditionals
>
> 20.1 Usage of Conditionals
> ==========================
>
> Before using a conditional, you must define it by using
> `AM_CONDITIONAL' in the `configure.ac' file (*note Macros::).
>
>  -- Macro: AM_CONDITIONAL (CONDITIONAL, CONDITION)
>     The conditional name, CONDITIONAL, should be a simple string
>     starting with a letter and containing only letters, digits, and
>     underscores.  It must be different from `TRUE' and `FALSE' that
>     are reserved by Automake.
>
>     The shell CONDITION (suitable for use in a shell `if' statement)
>     is evaluated when `configure' is run.  Note that you must arrange
>     for _every_ `AM_CONDITIONAL' to be invoked every time `configure'
>     is run.  If `AM_CONDITIONAL' is run conditionally (e.g., in a
>     shell `if' statement), then the result will confuse `automake'.
>
>   Conditionals typically depend upon options that the user provides to
> the `configure' script.  Here is an example of how to write a
> conditional that is true if the user uses the `--enable-debug' option.
>
>     AC_ARG_ENABLE([debug],
>     [  --enable-debug    Turn on debugging],
>     [case "${enableval}" in
>       yes) debug=true ;;
>       no)  debug=false ;;
>       *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
>     esac],[debug=false])
>     AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])
>
>   Here is an example of how to use that conditional in `Makefile.am':
>
>     if DEBUG
>     DBG = debug
>     else
>     DBG =
>     endif
>     noinst_PROGRAMS = $(DBG)
>
>   This trivial example could also be handled using `EXTRA_PROGRAMS'
> (*note Conditional Programs::).
>
>   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 the
> current `if'.  Similarly you may specify the condition that is closed
> on the `endif' line:
>
>     if DEBUG
>     DBG = debug
>     else !DEBUG
>     DBG =
>     endif !DEBUG
>
> Unbalanced conditions are errors.  The `if', `else', and `endif'
> statements should not be indented, i.e., start on column one.
>
>   The `else' branch of the above two examples could be omitted, since
> assigning the empty string to an otherwise undefined variable makes no
> difference.
>
>   In order to allow access to the condition registered by
> `AM_CONDITIONAL' inside `configure.ac', and to allow conditional
> `AC_CONFIG_FILES', `AM_COND_IF' may be used:
>
>  -- Macro: AM_COND_IF (CONDITIONAL, [IF-TRUE], [IF-FALSE])
>     If CONDITIONAL is fulfilled, execute IF-TRUE, otherwise execute
>     IF-FALSE.  If either branch contains `AC_CONFIG_FILES', it will
>     cause `automake' to output the rules for the respective files only
>     for the given condition.
>
>   `AM_COND_IF' macros may be nested when m4 quotation is used properly
> (*note M4 Quotation: (autoconf)M4 Quotation.).
>
>   Here is an example of how to define a conditional config file:
>
>     AM_CONDITIONAL([SHELL_WRAPPER], [test "x$with_wrapper" = xtrue])
>     AM_COND_IF([SHELL_WRAPPER],
>                [AC_CONFIG_FILES([wrapper:wrapper.in])])
>
>
>
> On Sat, Nov 12, 2011 at 12:01:04PM +0530, Ramana Reddy wrote:
> > Thank you very much Ben for your reply. I have one more doubt regarding
> how
> > to add our own
> > files( Assume that it is in the ovs/lib directory and the files are
> > dpif-mine.c and dpif-mine.h) to
> > automake.mk file in ovs/lib directory without adding immediately after
> the
> > existing ovs/lib files.
> >
> > I mean, is it possible to write some thing like below in automake.mkfile,
> > after adding AC_DEFINE([Ramana], [1], [Enable Ramana's extensions.]) to
> > configure.ac, so that it controls both modified code in the existing
> files,
> > as well
> > as the newly added files to OVS.
> >
> > if Ramana
> > lib_libopenvswitch_a_SOURCES += \
> >                    lib/dpif-mine.c \
> >                    lib/dpif-mine.h
> > endif
> >
> >
> > Thanks,
> > Ramana Reddy.
> >
> > On Fri, Nov 11, 2011 at 10:29 PM, Ben Pfaff <blp at nicira.com> wrote:
> >
> > > On Fri, Nov 11, 2011 at 03:35:00PM +0530, Ramana Reddy wrote:
> > > > I modified some code in OVS-1.2.2 both in user space and kernel
> > > > space with my own preprocessing directives some thing like:
> > > > #ifdef Ramana
> > > > /* my code is here */
> > > > #endif.
> > > >
> > > > Now I want to enable my code during the compilation of OVS-1.2.2.
> > > > This can be done by defining #define ramana in the header file and
> > > > adding this header file in the respective places can solve the
> problem.
> > > > But some how I do not like to add this header file in all the places.
> > > > How can we enable this preprocessor directive with out adding a
> header
> > > file.
> > > > Can we pass this one as a parameter to gcc like gcc -Dramana during
> > > > compilation.
> > > > if yes, where I should modify in the configuration file or some other
> > > file.
> > >
> > > Add AC_DEFINE([Ramana], [1], [Enable Ramana's extensions.])
> > > to configure.ac.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20111112/52525bcc/attachment.html>


More information about the discuss mailing list