Hi,
I am trying to include .so file and header files provided by a hardware
firmware using autotools.
I have tried using AM_CPPFLAGS= -I/usr/abc/inc and AM_LDFLAGS= -L/usr/abc/lib,
but I get these are directories as a warning. Also when I tried using
AM_LDFLAGS= /usr/abc/lib/libsrl.so but I get
On 09/15/2012 03:06 AM, Matt Turner wrote:
> I started thinking about this again recently, so I thought I'd respond.
>
> So, first thanks for the email and the suggestion.
>
> On Sat, Jul 14, 2012 at 1:42 AM, Stefano Lattarini
> wrote:
>> On 07/13/2012 07:16 PM, Matt Turner wrote:
>>> Hi,
>>>
>>
I started thinking about this again recently, so I thought I'd respond.
So, first thanks for the email and the suggestion.
On Sat, Jul 14, 2012 at 1:42 AM, Stefano Lattarini
wrote:
> On 07/13/2012 07:16 PM, Matt Turner wrote:
>> Hi,
>>
>> In Mesa (http://www.mesa3d.org/) we generate some C++ cod
On 07/13/2012 07:16 PM, Matt Turner wrote:
> Hi,
>
> In Mesa (http://www.mesa3d.org/) we generate some C++ code using
> Bison. The input is glsl_parser.yy and automake-1.11 and prior
> versions generated glsl_parser.h. 1.12 generates glsl_parser.hh, and
> if the input file is named .ypp it generat
Hi,
In Mesa (http://www.mesa3d.org/) we generate some C++ code using
Bison. The input is glsl_parser.yy and automake-1.11 and prior
versions generated glsl_parser.h. 1.12 generates glsl_parser.hh, and
if the input file is named .ypp it generates a .hpp file. How can we
configure our build system s
* Jef Driesen wrote on Wed, Mar 17, 2010 at 01:23:09PM CET:
> On 16/03/2010 14:22, Peter Johansson wrote:
> >Which method to use depends on where you want the MY_REVISION_VERSION to
> >propagate. Do you need it in any Makefiles, e.g., or do you only need it
> >compiled into your program.
>
> I onl
Hi Jef,
On 3/17/10 8:23 AM, Jef Driesen wrote:
I only need it compiled into my library. The goal is that an
application using my library can report the exact revision of the
library (for diagnostic purpose).
With the solution I outlined in my previous posts, I can already get
the "normal" ve
On 16/03/2010 14:22, Peter Johansson wrote:
On 3/16/10 8:29 AM, Jef Driesen wrote:
On 15/03/2010 22:18, Ralf Wildenhues wrote:
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
I suppose you are referring to solutions like this:
m4_define([mylib_version_revision],m4_esyscmd([my_rev
On 3/16/10 8:29 AM, Jef Driesen wrote:
On 15/03/2010 22:18, Ralf Wildenhues wrote:
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
I suppose you are referring to solutions like this:
m4_define([mylib_version_revision],m4_esyscmd([my_revision_script]))
where the revision script fe
On 15/03/2010 22:18, Ralf Wildenhues wrote:
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
For instance, I prefer to have:
typedef foobar ticks_t;
instead of:
#define ticks_t foobar
It might be possible to achieve the same with AC_CONFIG_HEADERS, but
I don't know how. I had a lo
* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
> On 13/03/10 11:34, Ralf Wildenhues wrote:
> >You are using a AC_CONFIG_FILES now instead of a AC_CONFIG_HEADERS.
> >That's fine per se, but config files are updated unconditionally by
> >config.status, meaning that the updated timestamp
On 13/03/10 11:34, Ralf Wildenhues wrote:
* Jef Driesen wrote on Mon, Mar 08, 2010 at 02:10:04PM CET:
On 02/03/10 22:17, Ralf Wildenhues wrote:
Hmm, put
AC_CONFIG_HEADERS([config.h foo-api.h])
...
AC_DEFINE([ticks_t], [...], [...])
in configure.ac, create foo-api.h.in with contents
* Jef Driesen wrote on Mon, Mar 08, 2010 at 02:10:04PM CET:
> On 02/03/10 22:17, Ralf Wildenhues wrote:
> >Hmm, put
> > AC_CONFIG_HEADERS([config.h foo-api.h])
> > ...
> > AC_DEFINE([ticks_t], [...], [...])
> >
> >in configure.ac, create foo-api.h.in with contents
> > /* Public API header o
On 02/03/10 22:17, Ralf Wildenhues wrote:
* Jef Driesen wrote on Tue, Mar 02, 2010 at 10:03:35PM CET:
On 01/03/10 19:35, Ralf Wildenhues wrote:
* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
Since a config.h header files is not supposed to be public, that's
not an option. Bu
On 3/3/2010 12:53 PM, Russ Allbery wrote:
John Calcote writes:
While I agree that standards should be followed, I find this one
distasteful. I mean, "long long"? Is that supposed to be someone's idea
of a scalable solution? What happens when we have 128-bit systems? Dare
I venture: "long l
John Calcote writes:
> While I agree that standards should be followed, I find this one
> distasteful. I mean, "long long"? Is that supposed to be someone's idea
> of a scalable solution? What happens when we have 128-bit systems? Dare
> I venture: "long long long"? And please don't say we'll nev
Sorry - I addressed this note to Jef. It should have gone to Ben. My
apologies.
On 3/3/2010 12:16 PM, John Calcote wrote:
Hi Jef,
On 3/3/2010 11:53 AM, Ben Pfaff wrote:
Jef Driesen writes:
It works fine for every system I have access too, but long long is not
standard and thus not guarante
Hi Jef,
On 3/3/2010 11:53 AM, Ben Pfaff wrote:
Jef Driesen writes:
It works fine for every system I have access too, but long long is not
standard and thus not guaranteed to be present. So I just want to make
sure it will work on other systems too.
"long long" has been standard for
Jef Driesen writes:
> It works fine for every system I have access too, but long long is not
> standard and thus not guaranteed to be present. So I just want to make
> sure it will work on other systems too.
"long long" has been standard for 11 years now. It is irritating
that some vendors have
* Jef Driesen wrote on Tue, Mar 02, 2010 at 10:03:35PM CET:
> On 01/03/10 19:35, Ralf Wildenhues wrote:
> >* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
> >>Since a config.h header files is not supposed to be public, that's
> >>not an option.
On 01/03/10 19:35, Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
How do I get information generated by autotools into my public
header files? For instance I want to define version numbers
somewhere in my configure.ac file, and have the same
Hello Jef,
* Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET:
> How do I get information generated by autotools into my public
> header files? For instance I want to define version numbers
> somewhere in my configure.ac file, and have the same numbers appear
> in a public
On Mon, Mar 1, 2010 at 7:33 AM, Jef Driesen wrote:
> Hi,
>
> How do I get information generated by autotools into my public header files?
> For instance I want to define version numbers somewhere in my configure.ac
> file, and have the same numbers appear in a public header file w
Hi,
How do I get information generated by autotools into my public header
files? For instance I want to define version numbers somewhere in my
configure.ac file, and have the same numbers appear in a public header
file without having to modify both files manually? Another example is
that my
Hi,
I have difficulties persuading automake to create header files from a
flex source using ylwrap. I tried the following:
foo_SOURCES = lexer.l parser.y
AM_LFLAGS = --header-file=lexer.h
but ylwrap doesn't create it; I also tried passing
%option header-file="lexer.h"
in th
* Ralf Wildenhues wrote on Mon, Mar 27, 2006 at 06:04:11PM CEST:
> * Jeff Safier wrote on Mon, Mar 27, 2006 at 05:58:31PM CEST:
> > Thanks for your answers. It seems automake does handle this
> > automattically, however we have a situation where the header files are
> > in a
Actually since I emailed I changed my INCLUDES=, and it seems to work
Thanks
-Original Message-
From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
Sent: Monday, March 27, 2006 11:04 AM
To: Jeff Safier
Cc: automake@gnu.org
Subject: Re: Way to generate header files automatically
Hi Jeff
Thanks for your answers. It seems automake does handle this
automattically, however we have a situation where the header files are
in a didfferent directory tree then the shource code. For that
dependency tracking is not working. Unless my INCLUDES= macro in my
Makefile.am is incorrect, im
Hi Jeff,
* Jeff Safier wrote on Mon, Mar 27, 2006 at 05:58:31PM CEST:
> Thanks for your answers. It seems automake does handle this
> automattically, however we have a situation where the header files are
> in a didfferent directory tree then the shource code. For that
> dependency
Hi Jeff
Jeff Safier wrote:
I am looking for a way that automake or any other tool to scan source
code (.c or .cpp) files and generate list of depedencies( meaning header
files) needed to compile the module. And if there is another tool how
to interface it with automake
I think Automake does
Do you mean SUBDIRS, DIST_SUBDIRS? Should include/ be in one of those?
>>
>>> Don't seem to have Makefile.am in every directory.
>>
>> Is this necessary? Is there a way to just say, "distribute everything
>> in
>> include/ and its subdirectories"? Th
ctory.
Is this necessary? Is there a way to just say, "distribute everything in
include/ and its subdirectories"? This would be an easy thing to add to
the toplevel Makefile.am.
Would it be easier if all the header files were just in lib/, where the
libgsutils.a archive is built? The onl
In my project source root, I have header files for a shared library in
a directory, 'include/'. Is there an easy way to get this directory
included in the build so 'make distcheck' will work? I'm not sure, but
it seems like the VPATH build is failing. 'make dist
>>> "Alan" == Alan Gutierrez <[EMAIL PROTECTED]> writes:
Alan> bin_PROGRAMS = foo
Alan> foo_SOURCES = \
Alan> src/foo/foo.hpp \
Alan> src/foo/foo.cpp
Alan> automake correctly determines the foo.hpp dependency for building foo,
Alan> but doesn't feed foo.hpp to etags.
% make tags
tags=; \
automake created a tags target that generates a TAG file using etags. It
does not pass headers. I've gone and done this:
bin_PROGRAMS = foo
foo_SOURCES = \
src/foo/foo.hpp \
src/foo/foo.cpp
automake correctly determines the foo.hpp dependency for building foo,
but doesn't feed foo.hpp to
> "Xabier" == Xabier Rodriguez Calvar <[EMAIL PROTECTED]> writes:
Xabier> include_HEADERS = hello-utils.h
Xabier> Doing this hello-utils.h is included as a headers file that
Xabier> belongs to hello project, but I want it to be included as
Xabier> libhello-util.
The easiest thing is to name
I'm learning to use automake and autoconf and I want to build a shared
shared library. My problem is that I don't know how to tell automake to
have to include the hearders file of my library in order to be installed
in the correct hearders directory.
bin_PROGRAMS = hello
hello_SOURCES = h
>>> "Neal" == Neal H Walfield <[EMAIL PROTECTED]> writes:
[...]
Neal> What I would like to happen is have make first run a "build-header"
Neal> target in each subdirectory which causes the header files to be
Neal> installed in $(top_builddir)/i
nique can be used with header files (substituting
AM_CPPFLAGS for VPATH, of course). This works well and does not
violate the abstraction--foo can know its own layout. A problem
arises however, when foo needs to use header files from other
directories. This is in fact quite common. Consider: foo
OK, please install.
adl> 2001-10-16 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl> * automake.in (am_install_var): Don't strip nobase_ from $X, do
adl> this with $nodir_name only.
Here is an update of this patch, which, I beleive, should fix
the bug reported by Braden McDaniel about nodist_noinst.
2001-10-17
[Please keep this discussion public.]
Martin Frydl <[EMAIL PROTECTED]> writes:
> Hello Alexandre,
> thank you for the patch. Now it does not complain about unknown
> variables, but another problem emerged. When installation is run, it
> does not create the subdirectorie
>>> "Martin" == Martin Frydl <[EMAIL PROTECTED]> writes:
[...]
Martin> nobase_include_HEADERS = dir1/file1.h dir2/file2.h
Martin> but I get errors:
Martin> include/Makefile.am:: variable `include_HEADERS' not defined
IMHO, Automake is stripping the 'nobase_' prefix at places it'd
rather no
Hi,
I'm not able to install header files in subdirectories. I've seen a
posting on this,
http://mail.gnu.org/pipermail/automake/2001-August/009388.html, but I'm
not able to make it work.
I have a directory containing just subdirectories with headers, no
other cod
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> One approach would be to use $(INSTALL_HEADER) which defaults to
Hari> $(INSTALL_DATA), and allow users to specify a special installer
Hari> if they choose. Of course, it would be nice if 'install' in
Hari> fileutils could be exte
On Oct 17, 2000, Raja R Harinath <[EMAIL PROTECTED]> wrote:
> Of course, it would be nice if 'install' in fileutils
> could be extended to provide a --only-if-change option.
Well, there's always move-if-change... But yes, that seems to be the
way to go. We shouldn't change what isn't broken; g
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> > This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel
> > or Jim could confirm it's OK.
>
> I have mixed feelings about this. At first, it may sound nice to not
> touch pr
On Oct 16, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel
> or Jim could confirm it's OK.
I have mixed feelings about this. At first, it may sound nice to not
touch pre-existing files. However, think of someone that uses
This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel
or Jim could confirm it's OK.
Hi,
it'd be nice if something like the attached patch could go into
Automake. It'd save a lot of recompiling for developers writing
libraries.
2000-10-02 Morten Eriksen <[EMAIL PROTECTED]>
* header.am (install-@DIR@HEADERS): Don't install a header file if
it is identical to th
50 matches
Mail list logo
