This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Details for svn test repository


Against my better judgement, i'll respond anyway.

On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote:
> On 2005-02-11, at 02:19, Daniel Berlin wrote:
> >
> > Uh, why do you want the server stuff for gcc purposes?
> 
> Just curious. Why not? If I want to try it out I want to try it out on 
> my own
> repos too. Maybe I was just too optimistic about it. And then I simply
> didn't know up front what I will get - just the client the server or 
> what else
> ot of it. configure --help didn't tell anything about it.

The configure script prints out copious messages about what it is going
to disable because of what dependencies, so you are either not paying
attention, or again, you are trolling.
> 
> > These are java bindings, if you don't use them, don't use them.
> 
> They are there. They have to be supported maintained and so on... they
> may break things if I suddenly update something on the system...
> And don't tell me this isn't going to happen. I did already enough 
> oracle
> installations in my life to get always nervous if I hear the word 
> Java...

So disable them if you are really worried about it.
Most people want them, so it's included by default if possible.
This is true of all the features you detest.

> 
> > Uh, you could simply build it with --disable-shared if you really
> > wanted
> 
> No this certainly didn't work. It was still building the shared stuff.
You need to be more specific.
No it isn't.
It still builds the libraries, but they are static. The libraries that
are necessary are built.

> 
> >> No problem I got APR. The apr -
> >> Fortunately it was possible to compile this thing with some tweaks.
> >
> > With some tweaks?
> > It should compile out of the box on osx. I've done it before.
> 
> The emphasis is on should...

It does.
If it does not, you need to report a bug against apr, including all of
your details.
I'm sure they will be glad to fix it.

> 
> >> However most of the
> >> dependencies couldn't be specified. The thing just went on to look for
> >> them no matter what I told it.
> >
> > Having built apr many many times, i've never seen this problem.
> 
> So look closer... Try disabling ldap: --without-ldap will give you a 
> link
> error for the library named well: "no".

Please file a bug against apr.  
> 
> >>  Didn't find much of the things already
> >> present in the OS. That much about a reproductible setup... Down the
> >> bin it is.
> >>
> >> subversion setup itself was no better. 
> >> mod_apache_blah/perl/python/ruby
> >> and what a not...
> >
> > It requires none of these things, it simply checks fo them, and will
> > build bindings if you like.
> 
> So I would like to be able to disable stuff I don't need. Nothing there 
> - no
> chance of something to be broken. (The perfect error free code - the 
> null code
> doing nothing!)

So disable them.
It tells you what happens!
The configure --help will also tell you, contary to your claims
otherwise.
> 
> >> Finally of course I was able to resolve those problems. But the
> >> questions remain:
> >>
> >> 1. What do I have? Which *kind* of subversion do I have? Checkouts 
> >> seem
> >> to work
> >>     but which "feature" do I miss?
> >
> > In the end, you have the same thing you would have gotten from a client
> > install.
> 
> No I like to know what I get. I like to know what the application 
> contains
> what it is supporting and so on. This can't be established for a naive 
> compile
> relying on configure scripts which have broken --disable-xxx or 
> --without-xxx directives.

If you have discovered a broken directive, please report a bug against
the approriate configure script.


> Call me pedantic. But this is what you get too if working long enough 
> in security
> sensitive environments. Maybe I'm not the windows generation which 
> didn't grow up
> with the impression imposed on them that crashing software is something 
> ethernal
> to life...
> 
> > What do you mean?
> > You can happily abort a checkout and restart it later through hitting
> > ctrl-c.
> 
> And now imagine you don't have an 1G connection working 24/7. Just 
> start the
> command and plug the LAN from you computer and watch svn never noticing 
> this.
> Press ctrl-c and watch svn never timing out... Good test for poorly 
> written
> software btw.
> 
> >>
> >> 5. The client didn't handle signals properly (^C). It was trying for
> >> ever to finish a
> >> transaction it should abort.
> >
> > For the database based server backend (not the filesystem based one),
> 
> A ha! There are multiple application which are posing as 
> subversion-server. So what is
> a subversion server?

Anything that speaks any of the protocols subversion clients speak, the
same way a cvs server is anything that speaks any of the protocols cvs
clients speak.

>  Which "backend" did I get during the configure
> process? Which backends did I get I never wanted to have? Wondering why
> this makes me nervous? Well maybe I did already see too much CERT 
> anouncments in
> my life...

Hey, maybe if you bothered to read what it said when you configured, or
you bothered to read the manual to see what the default is, you'd know.
Anyway, if you configure without berkeley db support, it will print:


You don't seem to have Berkeley DB version $db_version or newer
installed and linked to APR-UTIL.  We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end.  You can find the latest version of
Berkeley DB here:
  http://www.sleepycat.com/download/index.shtml
" >&5
echo "$as_me: WARNING: we have configured without BDB filesystem support


You don't seem to have Berkeley DB version $db_version or newer
installed and linked to APR-UTIL.  We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end.  You can find the latest version of
Berkeley DB here:
  http://www.sleepycat.com/download/index.shtml

Note that it tells you exactly what the default back-end is in case the
normal default (which is covered in the manual), is not available.

> A ha! Apparently the word transaction wasn't in the dictionary out 
> there?
Yes, well, this is external software.  I make no qualms about saying
that berkeley db has had its problems.

> Again poor quality for a new design. If a backend isn't as "secure" as 
> another
> and could cause things to break or even work differently. Well it 
> shouldn't
> be a back-end in first place at all.
blah blah, hindsight is 20-20.
Also, the FAQ goes over why bdb was ever a choice.

You can come up with a large list of complaints about configuring cvs,
configuring gcc, etc.

> I am talking about the fact that it wasn't possible to control the 
> feature set
> of this application. 

Yes it is, through configure options. If they don't work, FILE BUGS!

> That is an opinion but not a fact statement based on too much
> time spend in front of a linux distribution. Usually it's very well 
> defined

You have absolutely no clue what i develop on, and you are just trolling
again, Martin.

> what an oracle DB or a C99 compiler for example is. There are whole 
> organizations
> doing just this - defining what things are meant to be...
> 
> > Oh no, the configure script went looking to see if it could use already
> > installed libraries!
> 
> No it was using this information to enable and disable features.

Yes, of course, just like every other these days, *including the one we
are on the development list for* It will disable or enable various
assembler optimizations and debug output optimizations based on
configure tests. It also disables or enables other features based on
configure tests.  Some of these you can't override, even if you want to!
You may not like this, but this is what the majority of users want.

All i have heard from you is a bag of complaints that you don't want
subversion to be developed the way it is, you want to be able to define
the exact feature set of every application, and one bug in a configure
script.

My basic answers are
1. Sorry, it's their choice to develop it how they want, and to be
perfectly honest, it's a great product.  You could come up with the same
number and set of complaints about featuritis or whatever you have
against cvs, monotone, arch, and every other vcs out there. None are
perfect.
Your claims of poor quality are just opinion, and do not look very
informed, at least from my standpoint.

2. You are a dying breed, and are unlikely to be able to maintain your
control for very long.  Your best chance is gentoo linux, which will let
you try to configure oyur apps exactly how you like, but you probably
don't like linux anyway, because you believe it's development
methodologies will invariably lead it to failure.
3. File a bug report against apr, and i'm sure they will be happy to
help you make --without-ldap work.

I'm not sure what tweaking you think was required for apr.
./configure --prefix=whatever
<make, make install>
on osx, worked fine on 10.3.7 and 10.4 with absolutely nothing but the
os and developer tools installed.
Andrew Pinski has also confirmed that he built it with no problems.

--Dan
PS never try to build openoffice, you'll have an aneurysm



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]