Re: Public header files

[Jef Driesen]

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 look at a number of projects to see how
they did this, and they used AC_CONFIG_FILES.


Well, you can usually emulate such things with a helper #define and
conditional #if/#ifdef code in the manually written header.


That looks more complicated, and adds extra #ifdef's to the public 
header file that shouldn't be there in the first place.



The next thing I want to add is a MYLIB_VERSION_REVISION, that
contains some info from the SCM system (e.g. a svn revision number,
a git sha1 hash). When building a (not yet released) development
version of my code, it would be useful to know the exact revision.


There's been quite some prior discussion and examples of this in the
list archives, but a perfect solution still would require some changes
to Automake.


I suppose you are referring to solutions like this:

m4_define([mylib_version_revision],m4_esyscmd([my_revision_script]))

where the revision script fetches the revision from the SCM system,
or from a version file when using tarballs.


Well, that solution has the disadvantage that a revision change causes a
full autotools and configure rerun, but yes, that is one suboptimal
solution.


Is there a better method?

Re: Public header files

[Peter Johansson]

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 fetches the revision from the SCM system,
or from a version file when using tarballs.


Well, that solution has the disadvantage that a revision change causes a
full autotools and configure rerun, but yes, that is one suboptimal
solution.


Is there a better method?



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.


Peter

Re: build .o files to specific directory using automake

[scleung]

I have searched some related threads and seems that it won't work like this
way.
All suggestions were using VPATH build.
So does it possible to change the current directory in configure script to
specify the builddir?
I also try to override top_builddir variable with AC_SUBST but it seems not
work.



-- 
View this message in context: 
http://old.nabble.com/build-.o-files-to-specific-directory-using-automake-tp27918739p27927240.html
Sent from the Gnu - Automake - General mailing list archive at Nabble.com.

Re: build .o files to specific directory using automake

[Ralf Wildenhues]

Hello,

the message you reply to doesn't seem to have made it to the list,
other than to nabble.  It would have been helpful if you quote text
you reply to:

> > Usually makefile generated by automake will compile each source file
> > and output .o file in the same directory of the source file. How to
> > let automake output .o files to a specific directory at the same
> > time savely link them to my program/library?

* scleung wrote on Wed, Mar 17, 2010 at 03:29:15AM CET:
> I have searched some related threads and seems that it won't work like this
> way.
> All suggestions were using VPATH build.

Yes, indeed.  They are documented for example here:

Generally, this mechanism is more powerful and useful than moving
objects in a specific directory.

Another thing you might be interested in is the subdir-objects option;
.

> So does it possible to change the current directory in configure script to
> specify the builddir?

Yes, by calling the configure script *from* the builddir-to-be, i.e.,
with the builddir as current directory.

> I also try to override top_builddir variable with AC_SUBST but it seems not
> work.

No, that won't work.

Hope that helps.

Cheers,
Ralf