shared object and Makefile.am

Hi, I'm trying to use autotools to compile shared object Lua modules. The way these modules are named differs from the typical .so conventions because they're not actually libs one links against but are instead loaded by Lua itself. For example, a Lua module binding OpenGL would look like opengl.

Re: shared object and Makefile.am

On Sat, Jun 19, 2010 at 5:50 AM, Ralf Wildenhues wrote: > Hello Wesley, > > * Wesley Smith wrote on Sat, Jun 19, 2010 at 02:40:53PM CEST: >> I'm trying to use autotools to compile shared object Lua modules.  The >> way these modules are named differs from the typical

Re: shared object and Makefile.am

Also, one more follow up questions ... how can I have autotools not put things in the .libs hidden dir but in the source dir itself? wes

performing pre-build shell commands with automake

I've been looking through the automake docs trying to figure out how to execute shell commands as part of the build process but before anything actually gets compiled. Is this possible? I need this for things like Qt's 'moc' and some other script-based code generation utilities. thanks in advanc

Re: performing pre-build shell commands with automake

> However, that said, the correct way to do what you want is to place a > make dependency between the sources you want to generate, and the > consumers of those sources. Automake generates normal makefiles (or > rather makefile.in templates for Autotconf) from Makefile.am files. Some > of the code

Re: performing pre-build shell commands with automake

>> >> consumer.o: resource.qt > How does one do this kind of thing when the source file is specified in a subfolder? INCLUDES = -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb -I/usr/include/freetype2 lib_LTLIBRARIES = cairo.la cairo_la_LDFLAGS = -module -avoid-version cairo_la

Re: performing pre-build shell commands with automake

I also tried using lcairo.lo, which triggered the preliminary shell commands but barfed because the commands didn't generate lcairo.lo. hmm.. Is there a way to print out what rules were invoked during a make invocation? wes On Sun, Jun 20, 2010 at 10:14 PM, Wesley Smith

Re: performing pre-build shell commands with automake

> Build once without your qt dependencies in place and carefully note the > name and relative location of the object file generated from > src/lcairo.c. The qt dependency rule will have to look like this: > > exact-name-and-relative-location-of-object : resource.qt > > This is the short answer. You

Re: performing pre-build shell commands with automake

>> There are 2 issues I see: >> 1) Why would the Makefile.am below produce 2 commands compiling the >> same source file into 2 different directories? >> > > The two libtool commands are not exactly alike. The first command > generates position-independent code (PIC) to be used in your libtool > sha

checking for optional dependencies

I'm looking for some sample code on how to best check for an optional dependencies (like gstreamer or some other lib) and set a compilation flag like -DMYLIB_HAVE_GSTREAMER. I'm not exactly which one of these functions or how to use them to do this, so any pointers to a sample is much appreciated.

determining 32 v. 64 bit compilation

What's the appropriate way to determine 32 v. 64 bit compilation? I've looked into using: AC_CANONICAL_BUILD with the $build_cpu $build_vendor $build_os variables, but it doesn't give the right info (in my case i686 pc linux-gnu). I'm essentially looking for something in autoconf land equivalent

Re: determining 32 v. 64 bit compilation

no problem. I'll take the Q over there. wes On Tue, Jun 29, 2010 at 8:06 PM, Stefano Lattarini wrote: > At Tuesday 29 June 2010, Wesley Smith wrote: >> ... I'm essentially looking for something in autoconf land ... > I think you should write to the autoconf list (autoc...@

conditionals in Makefile.am

> From the automake manual: 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 curren

custom install paths

I've been reading ch12 in the automake manual, trying to make heads or tails of how to setup a custom install location as a default that can be overridden by the user. Here's an example Makefile.am AM_CPPFLAGS = -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb -I/usr/include/fre

Re: custom install paths

> Surely not given that you're generating the module by compiling code. > /usr/lib/lua/5.1, perhaps? Actually you're right. Egg on my face. I looked into how other packages like Lua Socket do it They put symlinks in /usr/lib/lua/5.1 to the actual compiled libs in /usr/lib. Here are the Lua Soc

Re: custom install paths

> luadir = $(LUA_DIR) > lua_LTLIBRARIES = cairo.la ok, one more thing. I understand what's going on with the above code with *dir matching *_LTLIBRARIES, but before you posted that code, I had not idea that such things were possible. In other words, I thought lib_LTLIBRARIES was a single variabl

Re: custom install paths

> Maybe these can help (please read them in the order given here): >   >   >   >  

build and installation names

I'm trying to setup a Makefile.am such that the lib and modules I build get installed in the following way: /usr/local/lib/liblua5.1-mymodule.so.0.0.0 /usr/local/lib/liblua5.1-mymodule.so.0 /usr/local/lib/lua/5.1/mymodule.so As a start, I tried to see if I could just build liblua5.1-mymodule.so.

Re: build and installation names

Thanks for all the help. I'll address the paths in later refinements, but for now, I'd like to understand why the error is happening in this particular instance. > I'm not quite sure what you mean with this.  Can you give an example? > Or do you mean the translation from >  lib_LTLIBRARIES = lib