[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C# support for automake
From: |
Ralf Wildenhues |
Subject: |
Re: C# support for automake |
Date: |
Tue, 6 Dec 2005 08:25:36 +0100 |
User-agent: |
Mutt/1.5.11 |
* Bruno Haible wrote on Mon, Dec 05, 2005 at 10:56:04PM CET:
> Ralf Wildenhues wrote:
>
> > > > How does the installed program find its libraries?
> > > > How the uninstalled?
> > >
> > > In both cases: through the -L option passed to csharpexec.sh. Inside
> > > csharpexec.sh, for some C# engines, the -L option translates into
> > > options; for others, it translates into the setting of an environment
> > > variable.
> >
> > Hmm, so somebody still has to play the 'gimme the uninstalled paths'.
> > At least I don't see that it is done automatically.
>
> Yes. I think only the strong names of dependencies are hardcoded into
> .dlls and .exes, not the paths where to find them.
So people rely on installed paths being default-findable by the engine?
> > In the case
> > proggie_exe_LDADD = -L ../libs -lfoobar
> >
> > so maybe you want the Makefile to create (uninstalled!) proggie with
> >
> > exec $top_builddir/csharpexec.sh -L ../libs -lfoobar proggie.exe
> >
> > in it?
>
> I agree, something like this (without the -lfoobar, just the -L option)
> should be done in the Makefile.
OK.
> > Are inter-library dependencies specified?
>
> As far as I know, inter-library dependencies are handled automatically.
> In other words, you link against A.dll and you don't care whether A.dll
> depends on B.dll or C.dll or both. You thus never have to compute the
> transitive closure of the needed DLLs. But you _do_ have to specify
> the complete list of directories where to find DLLs.
Hmm. This sounds like pretty much the same requirements as for Debian's
libtool (with link_all_deplibs=no) and
hardcode_direct=no
hardcode_automatic=no
hardcode_minus_L=no
hardcode_shlibpath_var=unsupported (?)
I say sounds, because I still don't like the idea of bringing the
comparatively huge machinery that is libtool into play just for this
task. OTOH, for a project that already uses libtool, adding a tag for
CS would (in CVS libtool) mean only negligible overhead.
Cheers,
Ralf
- C# support for automake, Bruno Haible, 2005/12/05
- Re: C# support for automake, Tim Van Holder, 2005/12/05
- Re: C# support for automake, Simon Josefsson, 2005/12/05
- Re: C# support for automake, Ralf Wildenhues, 2005/12/05
- Re: C# support for automake, Bruno Haible, 2005/12/05
- Re: C# support for automake, Jirka Hanika, 2005/12/11
- ax_prog_csc / Re: C# support for automake, Guido Draheim, 2005/12/21
- Re: ax_prog_csc / Re: C# support for automake, Bruno Haible, 2005/12/21
- Re: ax_prog_csc / Re: C# support for automake, Guido Draheim, 2005/12/21
- Re: ax_prog_csc / Re: C# support for automake, Guido Draheim, 2005/12/21
- Re: C# support for automake, Tim Van Holder, 2005/12/05