Re: "Sublibraries" without libtool
Hello Yevgen, * Yevgen Muntyan wrote on Mon, Nov 13, 2006 at 09:32:11PM CET: > > I am trying to figure out how to avoid using libtool when I don't need a > shared library. [...] > subdir1/ > libsubdir1.la > subsubdir1/ > libsubsubdir1.la > subsubdir2/ > libsubsubdir2.la Try using a nonrecursive makefile setup, so you don't need the intermediate convenience archives. Cheers, Ralf
Re: Overriding -g -O2
On 11/13/06, Paulo J. Matos <[EMAIL PROTECTED]> wrote: By passing CXXFLAGS='' to configure I was able to remove -g and -O2 but now with specific _CXXFLAGS during linking, no flags are showing up. What's the problem? And is passing an empty list of flags to configure the only way to achieve what I posted originally? You can change the variable at make time by passing `CXXFLAGS=options ...' to make.
Re: "Sublibraries" without libtool
Ralf Wildenhues wrote: * Yevgen Muntyan wrote on Mon, Nov 13, 2006 at 10:13:55PM CET: Well, I didn't mention it, but non-recursive make is one of things I am trying to do here. Its speed indeed is just awesome, but it also leads to huge mess: things like foo_SOURCES += subdir/subdir/subdir/foo.c subdir/subdir/subdir/bar.c; messy generated files stuff - to keep things nice I need to make sure subdirectories are created, which leads to creating some funny stamp files and failing distcheck; This is too thin for either a bug report or to point out decent help. A pointer to the source or an example package is better. It was neither actually. But, if someone wants to help me with non-recursive make setup, I will greatly appreciate it. Here's what I currently have (libtool and subdirs, "normal" thing): http://easynews.dl.sourceforge.net/sourceforge/mooedit/medit-0.7.95.tar.bz2 (sorry for sf.net link); and here's the best thing I got with non-recursive make: http://easynews.dl.sourceforge.net/sourceforge/mooedit/medit-0.6.99.tar.bz2 It worked nicely, but it was terrible mess. 'make dist' gets crazy and fails if you are not careful enough to not list things twice (this is really funny one - investigating why one file is put into dist four times can be pretty amusing); and so on. See above. I didn't actually think it's a bug, but it's a bug isn't it? If you do bin_PROGRAMS = foo bar foo_SOURCES = foo.c bar.c bar_SOURCES = foo.c bar.c then 'make dist' will put foo.c and bar.c twice on the command line which is used to pack them (copies them to dist dir or whatever it does). In case of non-recursive setup, with lots of files, such doubling (and often more than doubling) leads to "command line too long" errors. You do know about AC_DISABLE_SHARED by the way, just in case you didn't know about saving that factor of 2 (with Libtool, I mean)? Yes, I do. I have AC_DISABLE_STATIC in configure.ac (DISABLE_SHARED doesn't seem to be faster, and I do build shared libs). I guess it helps, but still no libtool is much faster. By the way, do I understand it right that there's no way to make libs LIBRARIES be clever like LT_LIBRARIES, wrt to LIBADD stuff? Best regards, Yevgen
Re: "Sublibraries" without libtool
Ralf Wildenhues wrote: Hello Yevgen, * Yevgen Muntyan wrote on Mon, Nov 13, 2006 at 09:32:11PM CET: I am trying to figure out how to avoid using libtool when I don't need a shared library. [...] subdir1/ libsubdir1.la subsubdir1/ libsubsubdir1.la subsubdir2/ libsubsubdir2.la Try using a nonrecursive makefile setup, so you don't need the intermediate convenience archives. Well, I didn't mention it, but non-recursive make is one of things I am trying to do here. Its speed indeed is just awesome, but it also leads to huge mess: things like foo_SOURCES += subdir/subdir/subdir/foo.c subdir/subdir/subdir/bar.c; messy generated files stuff - to keep things nice I need to make sure subdirectories are created, which leads to creating some funny stamp files and failing distcheck; compilation flags are hard to specify on per-directory basis; 'make dist' gets crazy and fails if you are not careful enough to not list things twice (this is really funny one - investigating why one file is put into dist four times can be pretty amusing); and so on. For now, I'd be happy to just avoid using libtool. Best regards, Yevgen
"Sublibraries" without libtool
Hello, I am trying to figure out how to avoid using libtool when I don't need a shared library. The current, "normal", setup is like this: I have a toplevel library which gets built into the executable, it gets built from libs from subdirs, and those subdirs in turn have subdirs with convenience libraries. It looks like this: libtoplevel_la_LDADD = subdir1/libsubdir1.la subdir2/libsubdir2.la libsubdir1_la_LDADD = subsubdir1/libsubsubdir1.la subsubdir2/libsubsubdir2.la ... subdir1/ libsubdir1.la subsubdir1/ libsubsubdir1.la subsubdir2/ libsubsubdir2.la It works fine if I'm using libtool, the libraries from nested subdirs get somehow correctly picked up and built into the executable (I guess it simply lists object files in la files in some way). Now, if I replace those libtool libs with automake LIBRARIES, then it no longer works, and I need to list *all* the static libs built in all subdirectories on the myexe_LIBADD line. How can I avoid this, to have convenience libraries take care of themselves, so I could link the executable to a single libtoplevel.a? Is this possible without reimplementing what libtool does? If you wonder why I want this, then it's very simple - no libtool is much much faster than libtool :) Thank you, Yevgen
Re: Using automake in conjunction with kbuild Makefile
Hi Stepan, first of all thanks for the fast answer. Stepan Kasal wrote: Hello Steve, I do not have any experience with kbuilt, but I'll try to generate some hins anyway: On Mon, Nov 13, 2006 at 11:48:29AM +0100, Steve Kreyer wrote: DEFAULT_INCLUDES = [EMAIL PROTECTED]@ two nits about this line: No need to use @..@, use $(abs_top_srcdir) instead. I have tried this but it didn't work... Why do you re-define DEFAULT_INCLUDES? Wouldn't it be more appropriate to use AM_CPPFLAGS? (But maybe I'm missing something.) It is needed because the module is buildet by kbuild outside the source tree, so I need absolute path names, but $(DEFAULT_INCLUDES) only provides the default include directories with relative paths... example a make distcheck will fail because the module sources will not be copied into the build environment of the distcheck... Thank you for the description of the situation, but I think your description of the actual problem could be more exact. `make distcheck' is just an automated way to check for features which should every package support. The feature you are speaking about is so called ``vpath build'', when srcdir != builddir. So you can do the same manually: make dist-bzip2 mkdir _check (cd _check ; tar xjf ../*.bz2) #chmod -R -w _check mkdir _build; cd _build ../_check/configure make Does this work? Does it work if you add the chmod command in the middle, to make the source tree read-only? No, it also don't work, with the same result that the needed source file is missing... But your example cleared my brain: Iam also no kbuild expert, but as described above kbuild compiles the kernel modules outside the source tree (vpath build), so it can't locate the sources in _build while running the distcheck and it fails... If not, what is the error message? Fix it or post it to this list to get some help. Or perhaps you are not willing to support vpath builds. (Does kbuild usually support them?) If that is the case, you do not want to use `make distcheck', at least not the complete version brought to you by automake. Have a nice day, Stepan Thanks, Steve
Re: Overriding -g -O2
On 11/13/06, Paulo J. Matos <[EMAIL PROTECTED]> wrote: Hi all, I'm trying to override -g -O2 CXXFLAGS set up by default but I'm quite confused on how to do this. I have specific _CXXFLAGS setup, I have also tried to setup AM_CXXFLAGS to empty but still those god damn flags show up when compiling and linking. How can I make them go away? By passing CXXFLAGS='' to configure I was able to remove -g and -O2 but now with specific _CXXFLAGS during linking, no flags are showing up. What's the problem? And is passing an empty list of flags to configure the only way to achieve what I posted originally? Regards, Paulo Matos Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Overriding -g -O2
Hi all, I'm trying to override -g -O2 CXXFLAGS set up by default but I'm quite confused on how to do this. I have specific _CXXFLAGS setup, I have also tried to setup AM_CXXFLAGS to empty but still those god damn flags show up when compiling and linking. How can I make them go away? Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Using automake in conjunction with kbuild Makefile
Hello Steve, I do not have any experience with kbuilt, but I'll try to generate some hins anyway: On Mon, Nov 13, 2006 at 11:48:29AM +0100, Steve Kreyer wrote: > DEFAULT_INCLUDES = [EMAIL PROTECTED]@ two nits about this line: No need to use @..@, use $(abs_top_srcdir) instead. Why do you re-define DEFAULT_INCLUDES? Wouldn't it be more appropriate to use AM_CPPFLAGS? (But maybe I'm missing something.) > example a make distcheck will fail because the module sources > will not be copied into the build environment of the distcheck... Thank you for the description of the situation, but I think your description of the actual problem could be more exact. `make distcheck' is just an automated way to check for features which should every package support. The feature you are speaking about is so called ``vpath build'', when srcdir != builddir. So you can do the same manually: make dist-bzip2 mkdir _check (cd _check ; tar xjf ../*.bz2) #chmod -R -w _check mkdir _build; cd _build ../_check/configure make Does this work? Does it work if you add the chmod command in the middle, to make the source tree read-only? If not, what is the error message? Fix it or post it to this list to get some help. Or perhaps you are not willing to support vpath builds. (Does kbuild usually support them?) If that is the case, you do not want to use `make distcheck', at least not the complete version brought to you by automake. Have a nice day, Stepan
Using automake in conjunction with kbuild Makefile
Hi,
I have a source package where a kernel driver is included.
I want to distribute this package with autotools.
Now I have a problem that I don't really know how automake
and the kbuild Makefile can work together...
I have the following Makefile.am:
--
KBUILD_MAKEFILE = ${srcdir}/Makefile.kbuild
EXTRA_DIST = Makefile.kbuild
DEFAULT_INCLUDES = [EMAIL PROTECTED]@
all-local:
$(MAKE) -f ${KBUILD_MAKEFILE} KERNELDIR=$(KERNELDIR)
EXTRA_CFLAGS="$(EXTRA_CFLAGS) $(DEFS) $(DEFAULT_INCLUDES)" RT=${RT}
clean-local:
$(MAKE) -f ${KBUILD_MAKEFILE} KERNELDIR=$(KERNELDIR) clean
--
This file is saved with the name "GNUmakefile.am". "Makefile.kbuild" is
linked at configure time to a file called "Makefile" so that the
kernel Makefile will found the Makefile for my module sources. So the
last lines of configure.ac:
---
AC_CONFIG_LINKS(most-kernel/Makefile:most-kernel/Makefile.kbuild)
AC_CONFIG_FILES([most-kernel/GNUmakefile])
AC_OUTPUT
---
This procedure works well to build the driver without problems, but for
example a make distcheck will fail because the module sources
will not be copied into the build environment of the distcheck...
So how can I use the kbuild Makefile in conjunction with automake?
Iam thankful for any hints you can give me, if you need additional infos
please let me know...
Best regards,
Steve
Re: sysconf_DATA v. dist_sysconf_DATA
Hello, On Fri, Nov 10, 2006 at 11:27:18AM -0700, David Everly wrote: > I have been working to follow this. It seems however that I need > dist_TESTS, but this seems to not work so perhaps I should do this > instead: > > EXTRA_DIST = $(TESTS) yes, that is fine. One nit about style: I would rather use dist_check_SCRIPTS = $(TESTS) Or perhaps the other way round. Let me give a more general example; perhaps some of the tests are compiled programs, some are built stripts and some are distributed scripts. Then you would have: check_PROGRAMS = foo bar foo_SOURCES = foo.c bar_SOURCES = bar.c baz.c nodist_check_SCRIPTS = this # this is created from this.in by configure dist_check_SCRIPTS = that another TESTS = $(check_PROGRAMS) $(nodist_check_SCRIPTS) $(dist_check_SCRIPTS) Have a nice day, Stepan Kasal
Re: adding libraries and header file directories
Hello Ralf,
On Fri, Nov 10, 2006 at 05:50:18PM +0100, Jim Rainville wrote:
> + aclocal-1.10 -I m4
...
> configure.ac:80: warning: macro `AM_LIBTOOLFLAGS' not found in library
On Sun, Nov 12, 2006 at 06:43:44PM +0100, Ralf Wildenhues wrote:
> The warning shouldn't be there. Please post the configure.ac code that
> deals with this, so we can find out whether there is a bug in automake.
just a quick inspection of the code shows that there is a bug in
aclocal. Observe:
; echo 'AC_SUBST( AM_CFLAGS, value)' >configure.ac ; aclocal
configure.ac:1: warning: macro `AM_CFLAGS' not found in library
;
If my guess is right, then the workaround is easy; use
AC_SUBST([AM_LIBTOOLFLAGS], [value])
which is the proper quoting anyway.
The code in aclocal.in looks like this:
if (! &search && /(^|\s+)(AM_[A-Z0-9_]+)($|[^\]\)=A-Z0-9_])/)
{ ...
msg (..., "warning: macro `$2' not found in library");
}
Actually, I think this whole `if' can be deleted. As a comment in
add_macro in aclocal.in puts it:
# Ignore unknown required macros. Either they are not really
# needed (e.g., a conditional AC_REQUIRE), in which case aclocal
# should be quiet, or they are needed and Autoconf itself will
# complain when we trace for macro usage later.
Have a nice day,
Stepan
