Justin Erenkrantz wrote:
> --On Wednesday, June 11, 2003 6:27 AM +0200 Patrick Mayweg <firstname.lastname@example.org>
> > I am sorry that you feal that way. I have posted the modifications twice to
> > the mail list. But nobody cared to answer. This patch is needed to configure
> > the java-bindings.
> The fact that no one 'cared to answer' does not mean that you should commit
> without prior review. We all are extremely busy and this is a high-traffic
> list. Some posts just slip through. You should keep reposting until someone
> replies, but please don't assume that silence equals review and assent.
> Please be patient though. (Two posts in less than two weeks isn't a long
What a frequency of reposts do you think is appropriate ? Daily, weekly or monthly
> That said, I believe that your patch/commit is incorrect as it tries to avoid
> the problem rather than resolve the issue raised in 751. It merely expands
> the abs_srcdir and abs_builddir at configure-time rather than teaching
> svn-config how to deal with installed copies of our dependencies. So, it
> doesn't serve to resolve the end problem as discussed in 751, but merely adds
> a layer of indirection that doesn't help anyone. It'll only work for your
> specific edge-case, but your edge-case isn't at all what svn-config was meant
abs_srcdir and abs_builddir are not known in svn-config. I could have introduced
them to the svn-config but it would have work alone, because the syntax for
variables in a shell script is different than for a Makefile.
What is what svn-config was meant for ? I thought it meant to give you the include
path and the libraries needed, when you want to build an appilication on top of the
subversion libraries. If you take a subversion release tarball, you will get the
abs_srcdir and the abs_builddir problem and the resulting Makefiles have to be
> In your particular case, the correct solution is to integrate your Java
> bindings into the Subversion build system. The top-level configure script has
> the knowledge of the variables needed to handle the location of the libraries.
> Therefore, you should submit patches to integrate those bindings into the main
> build system.
This is what I want to do. I just started with what I already had and adopted it
just as an intermediate step. To integrate into the build systems, I have to
understand them first. But since I have to process different kind of files (java
source and class files) as the rest of subversion, it may mean a major extentsion
to the buildsystems.
> You could either add the required logic to build.conf, or I'd personally be
> okay with having autoconf create the Makefile in the subversion/bindings/java
I did not had the time to try to understand the buildsystems. I also need to create
the dsp and ?vcproj? files on windows.
> I also noticed that you have introduced a dependency of automake into your
> bindings. So, you will have to remove those as the core of Subversion itself
> does not use automake.
This is only the intermediate step, I will remove automake, when I intergrate with
the build system.
> > svn-config does not need to be installed for the patch to work in the
> > current form.
> The problem is that svn-config wasn't meant to solve the problem of something
> in-tree needing the variables. The correct solution in your case is to
> generate the Makefiles from the top-level configure.
> I have a hunch that it *may* be better to scuttle svn-config and just create a
> pkg-config file. I'm not a great fan of pkg-config, but it may be able to
> solve the dependency problems in a way that is hard to do otherwise. -- justin
What is a pkg-config file ? Where do I find information about that ?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 11 08:01:08 2003