Sorry I have no idea how to properly reply to my initial message as I am not
subscribed to the mailing list. Anyhow..
Never thought I would write this, but extending Automake is really easy!
I'll write my solution here in case someone finds this with a search engine.
Below is what I came up wit
Hello, I have a C project which uses Autoconf and uses Lua for scripting.
I want Automake to be able to compile the Lua scripts to bytecode with "luac".
It is possible to compile a Lua script to bytecode like this:
luac -o myscript.luac myscript.lua
How do I instruct Automake to use luac to comp
Hello Bob,
On Tue, Aug 07, 2012 at 10:42:24PM -0500, Bob Friesenhahn wrote:
> >I've tried to use a Windows compiler (WindRiver Diab) with automake
> >under cygwin. The compiler gets cygwin-style paths (/cygdrive/c/...) on
> >its command line and fails. How can I make automake use cygpath for
> >co
On Tue, 7 Aug 2012, Baurzhan Ismagulov wrote:
I've tried to use a Windows compiler (WindRiver Diab) with automake
under cygwin. The compiler gets cygwin-style paths (/cygdrive/c/...) on
its command line and fails. How can I make automake use cygpath for
compilation (prog_SOURCES) and linking (pr
Hello,
I've tried to use a Windows compiler (WindRiver Diab) with automake
under cygwin. The compiler gets cygwin-style paths (/cygdrive/c/...) on
its command line and fails. How can I make automake use cygpath for
compilation (prog_SOURCES) and linking (prog_LDADD)? I see that there is
e.g. .S.ob
NightStrike writes:
>> suppose that my program is composed of 2 files f1.c and f2.c. f1.c is
>> written in C89 and f2.c in C99. I would like that f1.c is compiled
>> with a C89 compiler and f2.c is compiled with a C99 compiler.
>>
>> How can I achieve that in Makefile.am ?
>>
>> Also, in configur
On Thu, Jun 7, 2012 at 12:35 PM, Vincent Torri wrote:
> Hey
>
> suppose that my program is composed of 2 files f1.c and f2.c. f1.c is
> written in C89 and f2.c in C99. I would like that f1.c is compiled
> with a C89 compiler and f2.c is compiled with a C99 compiler.
>
> How can I achieve that in
Hey
suppose that my program is composed of 2 files f1.c and f2.c. f1.c is
written in C89 and f2.c in C99. I would like that f1.c is compiled
with a C89 compiler and f2.c is compiled with a C99 compiler.
How can I achieve that in Makefile.am ?
Also, in configure.ac, which macro should I use ? A
That's really what I was looking for. Thank you very much for your time!
--
From:
Sent: Tuesday, December 06, 2011 2:05 AM
To:
Subject: Re: Directions on compiling the right files
In other words, there will be new .c files that shou
> In other words, there will be new .c files that should be compiled
> only
> for the windows version and some .c files exclusive to the linux version.
> Suppose also I want to specify this at configure-time (e.g.
> "./configure" builds linux, "./configure --enable-win32" builds windows).
>
Hello,
I am a bit lost here. We recently started a project using GNU Build
System in order to make our package installable everywhere without mysteries
of package-specific builds.
Now I am facing a problem I will try to explain with an easier to
understand example.
Suppose I am making
Hello Hugh,
let's keep the list in Cc:, I dislike private communication about things
interesting for the public at large. Thanks.
* Hugh Dickinson wrote on Tue, Sep 28, 2010 at 09:34:13AM CEST:
> By the way, is the feature that you use for doing the suffix
> substitution (":.c=.cc") documented a
Hello Hugh,
* Hugh Dickinson wrote on Wed, Sep 22, 2010 at 04:50:33PM CEST:
> I am trying to convert an existing software package to build using the
> GNU autotools. The source code contains several files with .c and .cc
> which are designed to be compiled both as C and C++ regardless of
> their s
I am trying to convert an existing software package to build using the GNU
autotools. The source code contains several files with .c and .cc which are
designed to be compiled both as C and C++ regardless of their suffix (i.e. they
contain conditionally compiled code #ifdef _cplusplus preprocesso
I am trying to convert an existing software package to build using the GNU
autotools. The source code contains several files with .c and .cc which are
designed to be compiled both as C and C++ regardless of their suffix (i.e. they
contain conditionally compiled code #ifdef _cplusplus preprocesso
Hi,
On Mon, May 17, 2010 at 03:37:37PM -0700, Natalie Tasman wrote:
> I've created a separate configure.ac and Makefile.in for the "native"
> project. However, when invoking configuration from the top-level
> (cross-compiled) project, AC_CONFIG_SUBDIRS passes various options,
> including directi
Hello Simon,
I've created a separate configure.ac and Makefile.in for the "native"
project. However, when invoking configuration from the top-level
(cross-compiled) project, AC_CONFIG_SUBDIRS passes various options,
including directives to use the top-level cache as well as the "--host"
cross-com
On Sat, May 15, 2010 at 5:26 AM, Simon Richter wrote:
> It's more related to autoconf than to automake.
Oops :)
Sorry for replying too quickly on the autoconf list :(
Hi,
On Fri, May 14, 2010 at 03:53:29PM -0700, Natalie Tasman wrote:
> I have one target which is actually a utility used during *build* time. Is
> it possible to specify one target which should *not* be built with the
> cross-compiler, but natively instead?
Not directly. The trick is to have a
I'm working on a build system with autotools. I'd like to cross-compile,
building a mingw/windows executable from linux. So far, my system works
well with the --host option (and appropriate cross tools installed, from the
mingw-cross-env project.)
I have one target which is actually a utility us
> You don't need to specify -m32 if you have a tool set prefixed with the
> cross tag. The reason for using -m32 is because the user wants to use his
> 64-bit gcc to compile 32-bit code, so he has to tell the compiler to switch
> to 32-bit mode also. (Incidentally, if you're running on Linux, might
I'm curious about why setting "--host=i686-pc-linux-gnu" is not enough
to achieve cross compiling and why in that case it's not up to
autoconf to add "-m32" to CC.
You don't need to specify -m32 if you have a tool set prefixed with the
cross tag. The reaso
> You need a bi-arch system, that is, one that has the system libraries both in
> a
> 64-bit variant and in a 32-bit variant (typically in /lib64 and /lib,
> respectively).
> For compiling in 32-bit mode, I use
> ./configure --host=i686-pc-linux-gnu \
> --p
I would like to. But I'm not sure where I should start. While there are
a lot of descriptions how to use the autotools with supported languages,
I haven't found much about extending them. Could you give me some links?
That would be helpfull. I had problems understanding the m4 macros while
I had a
Hello Martin,
* Martin Kalbfuß wrote on Tue, Oct 13, 2009 at 11:21:13PM CEST:
> I want to create a library for the GNU-Modula compiler. But the
> libraries are pure object files in a separate directory. Some kind of
> package.
>
> Is there a target for this?
No. But if you write the compile rul
lan Stenn [mailto:st...@ntp.org]
Sent: Tuesday, October 13, 2009 6:31 PM
To: William Tracy (wtracy)
Cc: John Calcote; automake@gnu.org
Subject: Re: Difficulty cross-compiling
William,
I did a lot of what you are talking about when I was there - do you have
access to any of the ATC stuff?
H
William,
I did a lot of what you are talking about when I was there - do you have
access to any of the ATC stuff?
H
Hi,
I want to create a library for the GNU-Modula compiler. But the
libraries are pure object files in a separate directory. Some kind of
package.
Is there a target for this?
Thanks
On 10/12/2009 08:26 PM, William Tracy (wtracy) wrote:
Hello,
I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:
$ ./configure --host=ppc CC=/path/to/gcc CXX=/pa
This is a semi-embedded Linux system that I am trying to build for.
MontaVista is a Linux distribution that also provides a cross-compiling
toolchain--their own builds of the GNU toolchain, really. Their build
follows their own interesting naming convention, which isn't making this
si
Hi William,
On 10/12/2009 12:26 PM, William Tracy (wtracy) wrote:
I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:
$ ./configure --host=ppc CC=/path/to/gcc CXX=/p
Hello,
I'm trying to cross-compile a library that uses GNU Autotools (Google
Coredumper, to be specific) for PPC using the MontaVista tool chain. The
sequence of commands I'm following is:
$ ./configure --host=ppc CC=/path/to/gcc CXX=/path/to/g++
$ make
$ [next step would normally be "m
Jan Engelhardt writes:
>>needs to use $CC/$CXX anyway.
>
> CCLD/CXXLD.
Which default to $CC/$CXX anyway.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
You could use the -m32 compiler argument to ensure the creation of a
32bit binary
Greetings ...
On Sat, 2009-05-23 at 12:49 -0600, John Calcote wrote:
> Hi everyone,
>
> I was wondering what the procedure was for cross-compiling 32-bit apps
> on a 64-bin Linux system? Do you
On Sun, 24 May 2009, Jan Engelhardt wrote:
Bruno wrote:
The -m64 flag is the default on bi-arch Linux systems.
-m64 is the default on where it has been configured so. Just because
your shiny x86_64 install does that, does not mean it is universal.
Oftentimes RISCs, and sparc64 is usually one o
On Sunday 2009-05-24 16:25, Andreas Schwab wrote:
>Bruno Haible writes:
>
>> - The -m64 flag is the default on bi-arch Linux systems.
>
>This is wrong.
>
>> - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS.
>
>That should not be necessaray, since any command that uses $LD
Bruno Haible writes:
> - The -m32 flag has to be passed as part of both CC / CXX and LDFLAGS.
That should not be necessaray, since any command that uses $LDFLAGS
needs to use $CC/$CXX anyway.
> - The -m64 flag is the default on bi-arch Linux systems.
This is wrong.
Andreas.
--
Andreas S
> what the procedure was for cross-compiling 32-bit apps on a 64-bin Linux
> system?
You need a bi-arch system, that is, one that has the system libraries both in a
64-bit variant and in a 32-bit variant (typically in /lib64 and /lib,
respectively).
For compiling in 32-bit mode,
On Sat, 23 May 2009, John Calcote wrote:
Hi everyone,
I was wondering what the procedure was for cross-compiling 32-bit apps on a
64-bin Linux system? Do you need special libraries. What command-line options
are used? That sort of thing. I'm happy to read up on it, if there are
refer
On Saturday 2009-05-23 20:49, John Calcote wrote:
> Hi everyone,
>
> I was wondering what the procedure was for cross-compiling 32-bit apps on a
> 64-bin Linux system? Do you need special libraries. What command-line options
> are used? That sort of thing. I'm happy to read up
Hi everyone,
I was wondering what the procedure was for cross-compiling 32-bit apps
on a 64-bin Linux system? Do you need special libraries. What
command-line options are used? That sort of thing. I'm happy to read up
on it, if there are references that you can point me to.
Than
Hello Christian,
* Christian Rössel wrote on Thu, May 07, 2009 at 04:09:47PM CEST:
> configure switches to cross-compiling mode if I call it with build !=
> host like in
>
> ./configure --build=powerpc64-unknown-linux-gnu
> --host=powerpc-bgp-linux-gnu CC=bgxlc
>
> Can
configure switches to cross-compiling mode if I call it with build !=
host like in
./configure --build=powerpc64-unknown-linux-gnu
--host=powerpc-bgp-linux-gnu CC=bgxlc
Can someone explain to me what implications that has for configure
checks and the build in general? I can see that configure
Hello Theo,
* Theo Markettos wrote on Mon, Dec 01, 2008 at 01:32:12PM CET:
> I'm trying to run an existing autoconf/automake setup in a cross compiler.
> The cross compiler script generally Does The Right Thing about setting up
> --build, --host etc etc.
> noinst_PROGRAMS = bf_test
> So far I've
I'm trying to run an existing autoconf/automake setup in a cross compiler.
The cross compiler script generally Does The Right Thing about setting up
--build, --host etc etc.
The Makefile.am has the line:
noinst_PROGRAMS = bf_test
where bf_test is a program run on the build system to generate som
On Mon, Oct 6, 2008 at 4:06 PM, Ralf Wildenhues <[EMAIL PROTECTED]>wrote:
> I don't think your issue has to do with automake at all; it rather looks
> like a GCC issue. I can't tell if all you need is to use '-Wl,' or if
> there is some limitation in the gcc driver that you need to work around.
>
Hello Thomas,
* Thomas Epperson wrote on Mon, Oct 06, 2008 at 12:41:19PM CEST:
> kernel_LDFLAGS = -nostdlib -lgcc -T $(srcdir)/x86/link.ld
>
> I need to specify nostdlib and lgcc at the same time. But when I do it this
> way, lgcc gets ignored and the functions in it do not get linked in. I think
I am using autotools to cross-compile. It has worked great for me until now.
Here is the line in my makefile.am that I am having problems with.
kernel_LDFLAGS = -nostdlib -lgcc -T $(srcdir)/x86/link.ld
I need to specify nostdlib and lgcc at the same time. But when I do it this
way, lgcc gets ignor
f X86
syscalls.c: syscallsx86.c
#something?
endif
if ARM
syscalls.c: syscallsarm.c
#or something else?
endif
ACLOCAL_AMFLAGS = -I ../../..
CONFIG_STATUS_DEPENDENCIES = $(newlib_basedir)/configure.host
--
View this message in context:
http://www.nabble.com/Compiling-an-object-file
Hello Paulo,
* Paulo J. Matos wrote on Thu, Jun 26, 2008 at 02:34:50PM CEST:
> To compile a program fully-statically I do:
> ./configure CPPFLAGS="-DNDEBUG -I../../libfileIO-0.2.3/src"
> CXXFLAGS="-O3" LDFLAGS="-static-libgcc -static -Wl,-Bstatic
> -L../../libfileIO-0.2.3/src"
You can try somethi
Dear all,
I am sorry for the repetition of emails but my university internet
connection has been up and down lately and I thought it hadn't been
sent.
Truly sorry,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Hello all,
To compile a program fully-statically I do:
./configure CPPFLAGS="-DNDEBUG -I../../libfileIO-0.2.3/src"
CXXFLAGS="-O3" LDFLAGS="-static-libgcc -static -Wl,-Bstatic
-L../../libfileIO-0.2.3/src"
In the linking phase things go wrong:
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -s
Hello all,
To compile a program fully-statically I do:
./configure CPPFLAGS="-DNDEBUG -I../../libfileIO-0.2.3/src"
CXXFLAGS="-O3" LDFLAGS="-static-libgcc -static -Wl,-Bstatic
-L../../libfileIO-0.2.3/src"
In the linking phase things go wrong:
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -s
Hello all,
To compile a program fully-statically I do:
./configure CPPFLAGS="-DNDEBUG -I../../libfileIO-0.2.3/src"
CXXFLAGS="-O3" LDFLAGS="-static-libgcc -static -Wl,-Bstatic
-L../../libfileIO-0.2.3/src"
In the linking phase things go wrong:
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -s
eople won't know that it's necessary, and it seems redundant to
> me, because of the --host flag.
According to the pkg-config README, the way this is supposed to work
when cross compiling is to name the pkg-config script in the sysroot as
$host-pkg-config to differentiate it from the pk
John Darrington wrote:
> pkg.m4 doesn't behave in a very rational way, when configured with
> --host=xyzzy
I successfull use pkg-config when compiling from Linux to windows
using:
./configure --host=i586-mingw32msvc --target=i586-mingw32msvc
--build=i586-linux
My i586-ming
pkg.m4 doesn't behave in a very rational way, when configured with
--host=xyzzy
All the PKG_CHECK_MODULES macros continue to find the local modules,
not the ones for target xyzzy.Consequently, the build fails when
the compiler/linker can't find the header/library for the necessary
packages.
Hello Jason,
* jasond wrote on Tue, Jan 22, 2008 at 08:28:58PM CET:
>
> I have a
> project that will be comprised of two key subbranches: one containing C++
> code that can be compiled into a couple of different libs and a second
> branch that contains "mex" files. When I say, "mex" file I speci
Thanks in advance!
Jason
--
View this message in context:
http://www.nabble.com/Compiling-project-requiring-w--source-requiring-different-compilers-tp15026216p15026216.html
Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
I'm having troubles building a large ocaml library, where code is
divided into subdirectories for maintainance ease, as each of them
relies on optional dependencies.
The final stage (linking) has to be done from the top-level directory,
so as to create a single library. As linking order is strict,
Hello,
On Fri, Sep 22, 2006 at 10:54:20PM +0800, Tzu-Chien Chiu wrote:
> 2006/9/22, Stepan Kasal <[EMAIL PROTECTED]>:
> >But this does not mean tha BUILD_CC has to be set!
> >If BUILD_CC is empty, this just makes CC empty. AC_PROG_CC then does
> >its work. (The variable CC overrides the test onl
2006/9/22, Stepan Kasal <[EMAIL PROTECTED]>:
But this does not mean tha BUILD_CC has to be set!
If BUILD_CC is empty, this just makes CC empty. AC_PROG_CC then does
its work. (The variable CC overrides the test only if it is nonempty.)
1. I understand, but under which circumstances native
le to support this, you'll need to implement a toptevel
> configure script, which configures sub-directories this way. [...]
And the trick in Texinfo is based on this, of course.
But the native build is performed in a subdirectory of the main build
directory.
So when cross-compiling, a se
On Thu, Dec 08, 2005 at 01:37:26PM +0100, Ralf Wildenhues wrote:
> > but most of th time I don't need debug code, so I want to disable that
> > -g - option.
>
> So standard way with Automake-using projects would be: you make a debug
> build tree and a normal (optimized) build tree:
>
> mkdir buil
e CFLAGS=-O2
> And it is possible to do something similiar to the alternative compiling
> described above - i.e. to have a simple way for switching opt/debug mode,
> maybe
> without having to reconfigure?
make CFLAGS=-O2
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE
ure, then it deaults to "-g -O2".
To sum up:
1) give "CFLAGS=-O2" as an argument to ./configure
2) use CFLAGS=-g instead of make=debug
Yes, there are some difference:
With your old solution, the package maintainer prepared make=opt and such.
With the solution proposed above, _
Hi Daniel,
* Daniel Kraft wrote on Thu, Dec 08, 2005 at 10:24:26AM CET:
>
> Prior to using the GNU build system (especially automake) I used my own plain
> Makefiles which set compiler flags like -g, -O2
> or -Ds enabling assertions depending on a variable set on commandline. So it
> was
> possi
g this
way. What must be done to resolve this issue properly?
And it is possible to do something similiar to the alternative compiling
described above - i.e. to have a simple way for switching opt/debug mode, maybe
without having to reconfigure?
Thank you very much!
Yours,
Daniel Kraft
Hi Ralf,
It didn't work i just added umax4100 in BACKENDS. As i know after
autoconf i have to do automake right? but that require automake.am which
that package dont have.what can i do now?
regards,
Parag.
On 11/28/05, Parag N <[EMAIL PROTECTED]> wrote:
>
> Hi Ralf,
> Thanks. Actually i
Hi Ralf,
Thanks. Actually i thought as its adding/modifying GNU package task so
i ask here.
regards,
Parag.
On 11/28/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> * Parag N wrote on Mon, Nov 28, 2005 at 02:25:23PM CET:
> > On 11/28/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > >
> >
* Parag N wrote on Mon, Nov 28, 2005 at 02:25:23PM CET:
> On 11/28/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > What source rpm? Which package? From where? Name, URL needed.
> > link to source rpm is
> > http://download.fedora.redhat.com/pub/fedora/linux/core/4/SRPMS/sane-backends-1.0.
files:
Also show how it fails. Copy and paste, do not only use prose to
> explain technical issues.
Sorry but i didnot get how to show this but as u can see in above diff
output. the newly added files umax-4100.c is not compiling only the
original package is compiling besides asking .
* Parag N wrote on Mon, Nov 28, 2005 at 11:38:44AM CET:
> I downloaded source rpm.
What source rpm? Which package? From where? Name, URL needed.
> install it in /usr/src/redhat/SOURCES.
So your system is a RedHat or Fedora? Which version?
> then i extract it. I found directory back
ome files
> to
> > backend directory of sane package then i did aclocal,autocof,automake
> and
> > then when i make package make is not compiling my files. also i dont
> have
> > Makefile.am only have Makefile.in and by ./configure i am able to get
> > Makefile. what can
ocal,autocof,automake and
> then when i make package make is not compiling my files. also i dont have
> Makefile.am only have Makefile.in and by ./configure i am able to get
> Makefile. what can i do so that makefile will compile my files also. I also
> manually added files to be compiled in Mak
hello,
I am modifying one GNU Source package of sane application. What i
did is that i got source from SRPM and install it and added some files to
backend directory of sane package then i did aclocal,autocof,automake and
then when i make package make is not compiling my files. also i dont
You might want to check out the NTP code - I think I have something
in there to recompile a new 'version.c' on every link.
H
Ralf Wildenhues wrote:
> Hi David, Warren.
>
> * Warren Young wrote on Fri, Nov 04, 2005 at 01:49:42AM CET:
>
>>David Byron wrote:
>>
>>>What I'm having trouble with is getting the builddate.c recipe to happen
>>>at the right time.
>>
>>Could you make it depend on *.o except for builddate.o? I
On Friday, November 4th, Ralf Wildenhues wrote:
> Can't you just make it depend on the other source files?
>
> builddate.c: $(geoidx_SOURCES)
> echo ...
>
> Don't forget to mention the header file somewhere, by the
> way (in geoidx_SOURCES would be fine).
I could, but what about any
Hi Tim,
* Tim Van Holder wrote on Fri, Nov 04, 2005 at 04:33:49PM CET:
> Ralf Wildenhues wrote:
> >
> > Can't you just make it depend on the other source files?
> >
> > builddate.c: $(geoidx_SOURCES)
> > echo ...
>
> Well, it all depends on what "the build timestamp" is supposed to
how about this ? :
builddate.c: geoidx.c
echo $date > buildate.c
On 11/4/05, David Byron <[EMAIL PROTECTED]> wrote:
> This feels like a faq, but I couldn't find anything related so here
> goes.
>
> I'd like to compile in the build time into my application. I have a
> recipe like this:
>
Hi David, Warren.
* Warren Young wrote on Fri, Nov 04, 2005 at 01:49:42AM CET:
> David Byron wrote:
> >
> >What I'm having trouble with is getting the builddate.c recipe to happen
> >at the right time.
>
> Could you make it depend on *.o except for builddate.o? If any of those
> change, rebui
Hello,
On Thu, Nov 03, 2005 at 10:40:35AM -0800, David Byron wrote:
> geoidx: $(OBJS)
>
>
>
>
> But I'm not sure how to get automake to generate a Makefile like this.
one idea:
1) add a dependecy:
geoidx_DEPENDENCIES = builddate-stamp
(Look at the generated Makefile.in, if geoidx_DEPE
David Byron wrote:
What I'm having trouble with is getting the builddate.c recipe to happen
at the right time.
Could you make it depend on *.o except for builddate.o? If any of those
change, rebuild builddate.c, which will cause builddate.o to be rebuilt.
This feels like a faq, but I couldn't find anything related so here
goes.
I'd like to compile in the build time into my application. I have a
recipe like this:
BUILDTIME = $(shell TZ=UTC date --utc)
builddate.c:
echo "#include " >$@
echo >>$@
echo "const char *BuildDate
* v p wrote on Thu, Oct 07, 2004 at 01:08:54AM CEST:
> Hi Guys,
> I have a question. I am using autotools to build my static library.
> The way I do it is, I have a Makefile.am as
> lib_LIBRARIES = libmylib.a
> libmylib_a_SOURCES = xyz.c abc.c etc.
>
> The problem is the number of source files is
v p wrote:
I have a much faster build on windows and the windows project compiles
a bunch of files at a time.
Visual C++ is a much faster compiler than g++. automake and make do not
enter into it.
I have a much faster build on windows and the windows project compiles
a bunch of files at a time. So, I thought that might be the reason.
Looks like it is not.
-VP
On Wed, 06 Oct 2004 17:31:46 -0600, Warren Young <[EMAIL PROTECTED]> wrote:
> v p wrote:
> > Loading 'gcc' into memory for each file
v p wrote:
Loading 'gcc' into memory for each file is a time
consuming process
Have you measured this, or are you speculating?
If I could make generated makefile do this, my build
process will be much faster.
This is a limitation of make, not of the autotools.
On Wed, 6 Oct 2004, v p wrote:
Hi Guys,
I have a question. I am using autotools to build my static library.
The way I do it is, I have a Makefile.am as
lib_LIBRARIES = libmylib.a
libmylib_a_SOURCES = xyz.c abc.c etc.
The problem is the number of source files is huge (1659 files to be
precise) and t
Hi Guys,
I have a question. I am using autotools to build my static library.
The way I do it is, I have a Makefile.am as
lib_LIBRARIES = libmylib.a
libmylib_a_SOURCES = xyz.c abc.c etc.
The problem is the number of source files is huge (1659 files to be
precise) and that's why it takes a lot of ti
Hi,
I am new to automake and need to compile idl files
with a tao idl compiler, generating C++ files and then
compile them into object files.
Can somebody point me to sample code to accomplish
this using automake ?
Bob Beck
[EMAIL PROTECTED]
p://www.gnu.org/software/libtool/contribute.html
HTH,
Robert
-Original Message-
From: Martin Frydl [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 3:14 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Compiling 32-bit code on 64-bit HP-UX
Hello,
I'm trying to
$CC
_LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%' | $Xsed -e 's% .*$%%'`
# We don't want -fno-exception wen compiling C++ code, so set the
# no
Martin Frydl <[EMAIL PROTECTED]> writes:
>
> - config.guess does not use CFLAGS when making compilation checks but
> this can be "fixed" by providing necessary flags directly in CC
> variable
I think the cpu type guessed is supposed to depend only on the system,
not on an intended compiler mode.
better to teach Automake to byte-compile all
>> files at once rather than one at a time?
Ryan> Yes.
Here is a proposal. Could you check whether this solves the
problem in your particular instance ? :) The patch is against
CVS HEAD, I'll backport it to branch-1-7 if that
On Wed, Jan 08, 2003 at 02:46:34PM +0100, Alexandre Duret-Lutz wrote:
> Hi Ryan,
>
> As far as I can tell the other sources files are not necessarily
> in `..'. For instance during a VPATH-build we'd have to search
> them in `../$srcdir' (in case `$srcdir' is a relative path) or
> in `$srcdir' (i
time, whereas elisp-comp
Ryan> is expecting ALL .el files to be passed in. Thus I get
Ryan> While compiling toplevel forms in file
Ryan> /home/ryants/projects/doxymacs/lisp/elc.14611/doxymacs.el:
Ryan> !! File error (("Cannot open load file" "xml-parse"))
= no; then \
EMACS=$(EMACS) $(SHELL) $(elisp_comp) $<; \
else : ; fi
byte compiles each file one at a time, whereas elisp-comp is expecting
ALL .el files to be passed in. Thus I get
While compiling toplevel forms in file
/home/ryants/projects/doxymacs/lisp/elc.14611/doxymacs.el:
Hi!
i just downloaded latest automake version and get the problem.
i have parser.yy file which is in the SOURCES list.
while making the project i got a error:
no target parser.cpp to build parser.lo (or something like this - i
can't remember the message exactly.)
The problem was solved by adding pa
1 - 100 of 154 matches
Mail list logo
