automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linking a directory into several projects


From: Ralf Wildenhues
Subject: Re: Linking a directory into several projects
Date: Fri, 16 Sep 2005 09:02:56 +0200
User-agent: Mutt/1.4.1i

Hi Ian,

(Thanks, by the way, for replying back to the list.)

* Ian Crowther wrote on Thu, Sep 15, 2005 at 11:24:17PM CEST:
> >>In a typical c project I find myself duplicating certain things.
> 
> >What type of things?
> 
> Sorry, I was trying to be unspecific. My particular concern right
> now though is a directory of c source files (where the names of the
> files in the directory are liable to change). I want the directory
> of files to be used by all my c projects. If I add/delete/modify a
> file in the directory then I want that to be reflected by each
> project I have.

I'd do it like this: (just a bunch of untested commands to show where I
want to go)

# do this once:
cd $HOME/c-lib/libcompat
cat >Makefile.am <<EOF
noinst_LIBRARIES = libcompat.a
libcompat_a_SOURCES = src1.c ... hdr1.h ...

# do this once per package that uses libcompat
cd $HOME/package1
rm -f libcompat
ln -s $HOME/c-lib/libcompat libcompat
# now edit Makefile.am to contain `libcompat' in the list of SUBDIRs,
# like this or similar:
echo 'SUBDIRS += libcompat' >> Makefile.am
# make sure configure.ac contains AC_PROG_CC and AC_PROG_RANLIB,
# and AC_CONFIG_FILES contains libcompat/Makefile

End of example.

You should be able to maintain this structure if you are careful,
although libcompat/Makefile.in will generally be only correct for the
tree in which automake was issued most recently.  It would be very
helpful if libcompat would appear in the same subtree path in every
package, like: $top_srcdir/libcompat.

Another possibility, which would not be hacky as the one above, would be
to make libcompat a full subpackage.

In that case, libcompat would need a configure.ac itself.
Then, remove libcompat/Makefile from package1/configure.ac, and add
instead AC_CONFIG_SUBDIRS([libcompat]).

> >>If I create ~/c-lib/libcompat instead and
> >>"ln myproject/libcompat ~/c-lib/libcompat -s" then at build time

Please read the documentation of `ln' for how to use it correctly.
Sorry I overlooked before that you messed up the arguments.

> >(consider using $(LN_S) with AC_PROG_LN_S -- see docs for how to use
> it.)
> 
> I don't think that is any use. I don't wish to create links
> in a project that I distribute. I was trying to make my development
> easier by simply maintaining "~/c-lib/libcompat" and linking to that
> in each project during development. In the event that I build
> a distribution then I want the directory that I was linking to to
> be put into the tar. "make dist" does this for file or directory
> links.

Understood now.

> I'm not sure if I'm going about this in a very strange way... surely
> other people have this problem, how do they deal with it? I don't
> specifically want to use links; I just thought that they would
> be a good solution to the problem.

One possibility is to not use symlinks, but actually copy the stuff into
the tree.  The procedure of copying may be put into a small shell
script, and thus be easily redone with a simple command.  I believe this
is how GNULib's gnulib-tool and Libtool's libtoolize started their
life..

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]