[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Principles of a developing from a dist or install?
From: |
jling |
Subject: |
Re: Principles of a developing from a dist or install? |
Date: |
Sun, 04 Jan 2004 01:24:44 -0500 |
----- Original Message -----
From: Tom Tromey <address@hidden>
Date: Friday, January 2, 2004 10:46 pm
Subject: Re: Principles of a developing from a dist or install?
> >>>>> "John" == jling <address@hidden> writes:
>
> I can't say whether or not it makes sense. It isn't the standard
> thing, though, that's for sure. The typical approach is that "make
> install" simply installs the output of the build process, the idea
> being that the user can save some space by then deleting the source
> and build trees, if he so desires. Users who wish to hack on the
> package usually use the unpacked tree, both because it is already
> built (and therefore a simple change might involve less recompilation)
> and because it means these users and the maintainers will have a
> similar build structure and directory layout (so patches will apply
> more easily).
In my case, what I am distributing is a toolkit. So although there are
simple users who may only execute certain binaries that are built from
this distribution, these binaries are not the main focus of the install
and such users are not the main audience.
The primary class of users are application developers. With my package
I am envisioning/expecting these users to install the package somewhere
outside the source tree and into this install directory I would have
the built libraries placed in here. Application developers would then
need only look in one directory for all these libraries and one other
directory for related header files. In this case, the source tree can
then be completely wiped out.
Then a third class of users would be those who futher develop the
toolkit itself. These are the one's that I would want to give access
to the full deep tree structure for their hacking pleasure.
Such users do not need to
> John> Nevertheless what is the best way or ideal way to proceed?
>
> The general idea is to have one single structure used by everybody.
> This means less testing, less trouble applying patches, etc. People
> can generally navigate any sensible source layout, no matter how deep;
> I wouldn't normally consider that a big hurdle.
Your reasoning for a single structure makes complete sense to me and I
hope that I may convince others to see this reasoning and to go towards
a single structure.
Further comments and suggestions? By anyone?
John