,-O1 /home/simon/gnucobol/cobc/../cobc/cobc.c -o
>> ../cobc/cobc
>> /home/simon/gnucobol/cobc/../cobc/cobc.c:26:10: fatal error: config.h:
>> No such file or directory
>> #include "config.h"
>> ^~
>> compilation terminated.
>
> I
-Wno-format-y2k -U_FORTIFY_SOURCE
> -Wl,-z,relro,-z,now,-O1 /home/simon/gnucobol/cobc/../cobc/cobc.c -o
> ../cobc/cobc
> /home/simon/gnucobol/cobc/../cobc/cobc.c:26:10: fatal error: config.h:
> No such file or directory
> #include "config.h"
> ^~
> compilation te
bc/../cobc/cobc.c -o
../cobc/cobc
/home/simon/gnucobol/cobc/../cobc/cobc.c:26:10: fatal error: config.h:
No such file or directory
#include "config.h"
^~
compilation terminated.
~~~
where it should be (and normally does and also does on a second/third try):
~~~
gcc -D
On 03/01/2012 03:22 PM, Fabrício Zimmerer Murta wrote:
> Hello,
>
Hello Fabrício, sorry for the delay.
> I am unable to use automatic dependency tracking as I have been doing
> a project in Fortran 90. My problem is: when I change include/config.h,
> src/*.F90 which have th
Hello,
I am unable to use automatic dependency tracking as I have been doing a
project in Fortran 90. My problem is: when I change include/config.h, src/*.F90
which have the include/ file “included” are not recompiled (as would be
expected). I wonder if it would be okay just to add to the
I disagree that `make prefix=... install' is a poor man's DESTDIR.
Installing using DESTDIR will install things in
$(DESTDIR)/$(prefix)/bin (and so on), which is a right pain when it
comes to using something like GNU Stow to manage /usr/local.
-- Jack
On Tue, Jan 4, 2011 at 6:13 PM, Ralf Wildenhu
Hi Ralf - I figured out my problem. See below; basically, I'm a numbskull.
On Wed, Apr 22, 2009 at 1:09 AM, Ralf Wildenhues wrote:
> Here's a few reasons why this may not have worked as intended:
>
> - config.h wasn't even updated. configure, more precisely
> config
Hello Jason,
* Jason Sewall wrote on Tue, Apr 21, 2009 at 05:22:40PM CEST:
> I have a project using autoconf + automake + autoheader, and clearly
> the results of my builds depends on what is in config.h. Thus, I would
> expect that when I run ./configure, everything in the build tree w
I have a project using autoconf + automake + autoheader, and clearly
the results of my builds depends on what is in config.h. Thus, I would
expect that when I run ./configure, everything in the build tree would
be marked as out-of-date and everything would be rebuilt - that is, I
would expect
> I'm trying to the prefix to my config.h file, but when
> > > I do AC_DEFINE_UNQUOTED(PREFIX, $prefix) in my
> > > configure.ac file, the PREFIX in config.h gets defined
> > > to NONE.
> > See
> > <http://www.gnu.org/software/autoconf/manual/html_no
But I need it to be explicit, e.g. "/usr/share/",
On Feb 20, 2008 8:25 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Conrad,
>
> * Conrad Achtenbaum wrote on Wed, Feb 20, 2008 at 08:20:46PM CET:
> >
> > I'm trying to the prefix to my config.h
Hello Conrad,
* Conrad Achtenbaum wrote on Wed, Feb 20, 2008 at 08:20:46PM CET:
>
> I'm trying to the prefix to my config.h file, but when
> I do AC_DEFINE_UNQUOTED(PREFIX, $prefix) in my
> configure.ac file, the PREFIX in config.h gets defined
> to NONE.
>
> How do
Hi there,
I'm trying to the prefix to my config.h file, but when
I do AC_DEFINE_UNQUOTED(PREFIX, $prefix) in my
configure.ac file, the PREFIX in config.h gets defined
to NONE.
How do I export the prefix value?
Thanks in advance,
Jim Lynch wrote:
> Does anyone have a suggestion as to how I can automatically keep the svn
> revision number in a config file somewhere?
http://subversion.tigris.org/faq.html#version-value-in-source
Bob
I'd really like to be able to include the svn revision number somewhere
I can reference it from my program so I know which source revision is
running on a specific binary, in case I don't record that somewhere.
Before I moved to the gnu configuration setup I had a target in my
makefile that ch
$(datadir) part is expanded by make.
So you can do
./configure --prefix=oneprefix
make prefix=anotherprefix
make prefix=yetanother install
Your config.h approach doesn't allow the user to redifine prefix for
"make all", even though it allows them to redefine it for "make install
[Taking the discussion to the autoconf list.]
On Mon, Mar 07, 2005 at 09:57:31AM -0400, Leonardo Boiko wrote:
> Isn't config.h created at configure time? AFAIK directory installation
> variables should only be defined at make time. See
> ``info Autoconf "Installation Directo
[EMAIL PROTECTED] wrote:
I'm using SYSCONFDIR in one of my C source files. Currently I pass it
through the following definition:
AM_CFLAGS = ... -DSYSCONFDIR=\"@[EMAIL PROTECTED]"
This is cluttering the gcc command line, so I want to define it in
config.h.
Isn't config.h creat
Hello,
I'm using SYSCONFDIR in one of my C source files. Currently I pass it
through the following definition:
AM_CFLAGS = ... -DSYSCONFDIR=\"@[EMAIL PROTECTED]"
This is cluttering the gcc command line, so I want to define it in
config.h. However, I can't figure out
On Wed, 2 Apr 2003, Dale E Martin wrote:
> > > "make install" clutils is installing it's generated config.h, which has
> > ^
> > Don't do that.
> Meaning that none of my headers can #inlude &
> > "make install" clutils is installing it's generated config.h, which has
> ^
> Don't do that.
Meaning that none of my headers can #inlude "config.h"? That seems
ludicrous to me.
> You s
On Mon, 31 Mar 2003, Dale E Martin wrote:
> Am I not getting some fundamental concept of the intention of config.h
> files?
Yep - see below.
> Here's my problem; I've got several projects that depend on each other;
> several libraries that depend on each other in an or
Am I not getting some fundamental concept of the intention of config.h
files?
Here's my problem; I've got several projects that depend on each other;
several libraries that depend on each other in an orderly fashion. All of
them are using autotools for their build systems. One of the
Bruce Korb <[EMAIL PROTECTED]> writes:
http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html
thanks for the tip. fwiw, to try this i had to substitute
AC_ECHO_MKFILE(foo,bar)
with
echo 'foo' > bar
(the AC_ECHO_MKFILE from the website is empty.)
thi
due to missing extension packages.
* some ac-checks define missing things, most prominently the
ones for off_t and const.
how to handle them:
* place an pkg-conf.h along with the generated pkg-config.h,
which includes the latter, and all the other headers
include pkg-conf.h. This pk
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> Waldemar Rosenbach <[EMAIL PROTECTED]> writes:
>
>Is there another way to solve this kind of problem?
>
> well, it's not clean, but you can process the headers on install. this could
> be a provisional approach (i.e., kludge) while you make the
Thien-Thi Nguyen wrote:
>
> Thien-Thi Nguyen <[EMAIL PROTECTED]> writes (imprecisely):
>
>you can process the headers on install.
>
> sorry, i forgot to emphasize: the headers processed are those other than
> config.h -- the horrible approach described does
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes (imprecisely):
you can process the headers on install.
sorry, i forgot to emphasize: the headers processed are those other than
config.h -- the horrible approach described does not require you to install
config.h. (did i mention that this ap
Waldemar Rosenbach <[EMAIL PROTECTED]> writes:
Is there another way to solve this kind of problem?
well, it's not clean, but you can process the headers on install. this could
be a provisional approach (i.e., kludge) while you make the interface platform
independent.
see below for petrify-h
Waldemar Rosenbach <[EMAIL PROTECTED]> writes:
> But what is the best way to deal with the platform depend stuff in the
> interface?
A platform independent interface!
--
Ralph
config.h is platform depend, so it shouldn't be installed by make install.
But what is the best way to deal with the platform depend stuff in the
interface?
For example:
#ifdef HAVE_HASHMAP
# include
typedef std::hash_map myTableType;
#else
# include
typedef std::map myTabl
>>>>> "David" == David Petrou <[EMAIL PROTECTED]> writes:
David> include_HEADERS = pdl_config.h
David> This seems to imply that config.h should _not_ be distributed,
David> like I'm doing above. What's wrong with what I'm doing? If
Dav
Hi, I'm using automake 1.4 for a library called "pdl". I want to
include the generated config.h file in the installed library because
it sets crucial defines that are needed by users of the library. I'm
doing this by setting the following in my configure.in:
AM_CONFI
On Jan 21, 2001, John Poltorak <[EMAIL PROTECTED]> wrote:
> I'm not really sure where config.h falls into the scheme of building apps
> using AUTO(MAKE|CONF), but I've found that for PATCH to get built on OS/2,
> it requires this single addition to config.h:-
>
I'm not really sure where config.h falls into the scheme of building apps
using AUTO(MAKE|CONF), but I've found that for PATCH to get built on OS/2,
it requires this single addition to config.h:-
#define strncasecmp strnicmp
How would I go about getting this line included in c
On Mon, Oct 30, 2000 at 09:18:42AM -0800, Ossama Othman wrote:
> Hi Gary,
>
> On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote:
> > Hmmm. I think that installing config.h is a bad idea under any
> > circumstances. I talk about this in some detail in the ``P
On Tue, 31 Oct 2000, Simon Richter wrote:
> On Mon, 30 Oct 2000, Bob Friesenhahn wrote:
>
> > If we should not be installing config.h files, then it would be
> > beneficial for Automake (or Autoconf) to support an automated way to
> > provide the benefits of config
On Mon, Oct 30, 2000 at 07:41:21PM -0600, Bob Friesenhahn wrote:
: If we should not be installing config.h files, then it would be
: beneficial for Automake (or Autoconf) to support an automated way to
: provide the benefits of config.h, but in a better form.
You can use the generated
On Mon, 30 Oct 2000, Bob Friesenhahn wrote:
> If we should not be installing config.h files, then it would be
> beneficial for Automake (or Autoconf) to support an automated way to
> provide the benefits of config.h, but in a better form.
How about the bin/-config approach: configure
Hi, Ossama.
Ossama Othman <[EMAIL PROTECTED]> writes:
> However, sometimes this can't be avoided in the case of inlined
> functions (e.g. C++). It isn't always feasible, particularly in
> terms of performance, to always keep function implementations hidden
> within the library. One could argue
On Mon, 30 Oct 2000, Ossama Othman wrote:
>
> On Tue, Oct 31, 2000 at 01:40:30AM +0100, Assar Westerlund wrote:
> > I would agree with Gary here that the symptom is installing the
> > config.h (or whatever it's called). The problem is that the interface
> > exporte
Hi Assar,
On Tue, Oct 31, 2000 at 01:40:30AM +0100, Assar Westerlund wrote:
> I would agree with Gary here that the symptom is installing the
> config.h (or whatever it's called). The problem is that the interface
> exported from the library should not depend on the parameters
Ossama Othman <[EMAIL PROTECTED]> writes:
> If the macros placed in the package specific config.h are named so
> that they are specific to the given package then why is installing
> that header a problem.
I would agree with Gary here that the symptom is installing the
config.h (o
the headers more
> readable.
That's an interesting approach. I'll download the glib sources and
take a look. Thanks for the pointer!
> You can do that yourself
>
> sed 's,^#define ,#define FOO_,' < config.h > foo-config.h
Quite right, though I don'
Ossama Othman <[EMAIL PROTECTED]> writes:
> On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote:
> > Hmmm. I think that installing config.h is a bad idea under any
> > circumstances. I talk about this in some detail in the ``Project''
> > chap
need to have the configure generated config.h
> >
> > What is the "best" way to coerce Automake into installing
> > config.h in $(prefix) ?
>
> I must caution against installing config.h. You will collide with the
> potential same config.h and HAVE* et al defines
Hi Gary,
On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote:
> Hmmm. I think that installing config.h is a bad idea under any
> circumstances. I talk about this in some detail in the ``Project''
> chapters of the Goat Book (linked from my homepages), and
Some food for thought:
On Thu, Oct 26, 2000 at 02:20:10PM -0700, Ossama Othman wrote:
> Hi Alexandre,
>
> On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote:
> > If you really want to have it installed, don't call it `config.h', or
> > at le
Robert Boehne <[EMAIL PROTECTED]> writes:
> I have a massive set of C++ libraries that use
> CVS libtool, autoconf and automake to build and install.
> Since users then need to have _all_ the header files
> they also need to have the configure generated config.h
>
> W
Simon Richter <[EMAIL PROTECTED]> writes:
> On 27 Oct 2000, Mark Galassi wrote:
> [Installing config.h]
>
> > But be careful: if any of the C code in the package itself includes
> > you might be in for a nasty surprise: if
> > a version is already installed and
Hi,
On Fri, Oct 27, 2000 at 09:30:47PM +0200, Simon Richter wrote:
> On 27 Oct 2000, Mark Galassi wrote:
>
> [Installing config.h]
>
> > But be careful: if any of the C code in the package itself includes
> > you might be in for a nasty surprise: if
> > a vers
On 27 Oct 2000, Mark Galassi wrote:
[Installing config.h]
> But be careful: if any of the C code in the package itself includes
> you might be in for a nasty surprise: if
> a version is already installed and a user is compiling a new version
> from source, that user will pick up t
>> And use `#include ' in all other
>> headers that include it.
Ossama> BTW, I do exactly what Alexandre suggests in some of my
Ossama> own packages. It works out quite nicely.
But be careful: if any of the C code in the package itself includes
you might be in for a nasty surp
Ossama Othman wrote:
>
> Hi Alexandre,
>
> On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote:
> > If you really want to have it installed, don't call it `config.h', or
> > at least install it in include/. To accomplish
> > that, us
Hi Alexandre,
On Thu, Oct 26, 2000 at 07:13:28PM -0200, Alexandre Oliva wrote:
> If you really want to have it installed, don't call it `config.h', or
> at least install it in include/. To accomplish
> that, use:
>
> pkginclude_HEADERS = config.h ...
>
> A
On Oct 26, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Since users then need to have _all_ the header files
> they also need to have the configure generated config.h
> What is the "best" way to coerce Automake into installing
> config.h in $(prefix) ?
I
On Thu, 26 Oct 2000, Robert Boehne wrote:
[Finding libraries from other packages]
> What is the "best" way to coerce Automake into installing
> config.h in $(prefix) ?
Not at all. Instead, create m4 macros that search for the libraries
somehow and place them in ${datadir}/a
Hi Robert,
On Thu, Oct 26, 2000 at 01:32:42PM -0500, Robert Boehne wrote:
> I have a massive set of C++ libraries that use
> CVS libtool, autoconf and automake to build and install.
> Since users then need to have _all_ the header files
> they also need to have the configure genera
I have a massive set of C++ libraries that use
CVS libtool, autoconf and automake to build and install.
Since users then need to have _all_ the header files
they also need to have the configure generated config.h
What is the "best" way to coerce Automake into installing
config.h i
59 matches
Mail list logo
