* Hi, Pan-afrikander
From: Dorthy Graham @ 2006-06-15 1:21 UTC (permalink / raw)
To: linux-newbie
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://ltgwos.valvecedar.net/?18867733
==========
As he came from Earth now, above the clouds and in close formation
Pylon 27; the metal sign had a red circle with the number 27 in it. Kirill
about them, to press power into these new wings.
We pulled on the special suits. I poured the nuts and bolts from the
which the style and character of even a laundry list could hardly be
"Don't rush," I said. "No hurry. Less dust."
extraterrestrials, who leave behind them--well, call it litter, such as
1. REDRICK SCHUHART, AGE 23,
^ permalink raw reply
* Re: Collecting cvsps patches
From: Alexander Litvinov @ 2006-06-15 2:21 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060611224205.GF1297@nowhere.earth>
Your master branch is not compilable. This is the fix for it.
---
cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cache.c b/cache.c
index 409392d..2b2179a 100644
--- a/cache.c
+++ b/cache.c
@@ -501,7 +501,7 @@ static void dump_patch_set(FILE * fp, Pa
struct list_head * tag;
for (tag = ps->tags.next; tag != &ps->tags; tag = tag->next)
{
- TagName* tagname = list_entry (tag, TagName, tagnames);
+ TagName* tagname = list_entry (tag, TagName, name);
fprintf(fp, " %s %d%s", tagname->name, tagname->flags,
(tag->next == &ps->tags) ? "" : ",");
--
1.4.0
^ permalink raw reply related
* Hi, mummy case
From: Marquis Brennan @ 2006-06-15 8:22 UTC (permalink / raw)
To: linux-newbie
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://jsdhuu.motivefood.com/?23868551
=====
storm. Eyes glazed, beaks sharp, they closed in to destroy.
wriggling your fingers and cursing in frustration. OK, let's say you've got
that this was what they were doing.
The suits are too percent protection against the burning fluff, for example,
"Of course if you wish to learn."
"I'm looking for what I should be looking for. Wait, I'll throw another
end it all.
lowered an anchor on a steel cable from a helicopter and hooked a piece of
^ permalink raw reply
* Re: Collecting cvsps patches
From: Pavel Roskin @ 2006-06-15 3:08 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Yann Dirson, GIT list
In-Reply-To: <200606150921.34690.lan@academsoft.ru>
On Thu, 2006-06-15 at 09:21 +0700, Alexander Litvinov wrote:
> Your master branch is not compilable. This is the fix for it.
Actually, revision 5ecebc5064df0fd578dbf4b5ba5255e9af8cda7a renamed
"tagnames" to "link" in cvsps_types.h, so I think the same should be
done in cache.c.
Also, you can check the definition of list_entry, you'll see that the
member (argument 3) is cast to the pointer to the requested type
(argument 2). I don't think it's safe to cast name to a pointer to
TagName.
That said, having non-compilable repository defeats the purpose of
collecting the patches to cvsps. Shouldn't only compilable patches be
allowed in the repository?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Collecting cvsps patches
From: Alexander Litvinov @ 2006-06-15 3:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Yann Dirson, GIT list
In-Reply-To: <1150340912.24184.7.camel@dv>
> Actually, revision 5ecebc5064df0fd578dbf4b5ba5255e9af8cda7a renamed
> "tagnames" to "link" in cvsps_types.h, so I think the same should be
> done in cache.c.
>
> Also, you can check the definition of list_entry, you'll see that the
> member (argument 3) is cast to the pointer to the requested type
> (argument 2). I don't think it's safe to cast name to a pointer to
> TagName.
You are right. My patch is wrong. I have tried to import real cvs repo and
cvsps broke with sigsegv.
^ permalink raw reply
* [PATCH for cvsps] Handle cvs repo with modules
From: Alexander Litvinov @ 2006-06-15 5:49 UTC (permalink / raw)
To: git, Yann Dirson, cvsps
Parse 'Working file' lines from cvs log output. This alow to work with cvs repos
with modules. To enable this you need to add --no-rlog to cvsps command line args.
This patch was made to import such repo into git. But git-cvsimport can't load such data.
---
cvsps.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 2695a0f..62d6e08 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -39,7 +39,8 @@ #define CVS_FILE_BOUNDARY "=============
enum
{
- NEED_FILE,
+ NEED_RCS_FILE,
+ NEED_WORKING_FILE,
NEED_SYMS,
NEED_EOS,
NEED_START_LOG,
@@ -117,7 +118,9 @@ static int parse_args(int, char *[]);
static int parse_rc();
static void load_from_cvs();
static void init_paths();
-static CvsFile * parse_file(const char *);
+static CvsFile * build_file_by_name(const char *);
+static CvsFile * parse_rcs_file(const char *);
+static CvsFile * parse_working_file(const char *);
static CvsFileRevision * parse_revision(CvsFile * file, char * rev_str);
static void assign_pre_revision(PatchSetMember *, CvsFileRevision * rev);
static void check_print_patch_set(PatchSet *);
@@ -260,7 +263,7 @@ static void load_from_cvs()
{
FILE * cvsfp;
char buff[BUFSIZ];
- int state = NEED_FILE;
+ int state = NEED_RCS_FILE;
CvsFile * file = NULL;
PatchSetMember * psm = NULL;
char datebuff[20];
@@ -339,10 +342,26 @@ static void load_from_cvs()
switch(state)
{
- case NEED_FILE:
- if (strncmp(buff, "RCS file", 8) == 0 && (file = parse_file(buff)))
+ case NEED_RCS_FILE:
+ if (strncmp(buff, "RCS file", 8) == 0) {
+ if ((file = parse_rcs_file(buff)) != NULL)
state = NEED_SYMS;
+ else
+ state = NEED_WORKING_FILE;
+ }
break;
+ case NEED_WORKING_FILE:
+ if (strncmp(buff, "Working file", 12) == 0) {
+ if ((file = parse_working_file(buff)))
+ state = NEED_SYMS;
+ else
+ state = NEED_RCS_FILE;
+ break;
+ } else {
+ // Working file come just after RCS file. So reset state if it was not found
+ state = NEED_RCS_FILE;
+ }
+ break;
case NEED_SYMS:
if (strncmp(buff, "symbolic names:", 15) == 0)
state = NEED_EOS;
@@ -471,7 +490,7 @@ static void load_from_cvs()
have_log = 0;
psm = NULL;
file = NULL;
- state = NEED_FILE;
+ state = NEED_RCS_FILE;
}
else
{
@@ -524,7 +543,7 @@ static void load_from_cvs()
exit(1);
}
- if (state != NEED_FILE)
+ if (state != NEED_RCS_FILE)
{
debug(DEBUG_APPERROR, "Error: Log file parsing error. (%d) Use -v to debug", state);
exit(1);
@@ -1039,7 +1058,7 @@ static void init_paths()
* NOTE: because of some bizarre 'feature' in cvs, when 'rlog' is used
* (instead of log) it gives the 'real' RCS file path, which can be different
* from the 'nominal' repository path because of symlinks in the server and
- * the like. See also the 'parse_file' routine
+ * the like. See also the 'parse_rcs_file' routine
*/
strip_path_len = snprintf(strip_path, PATH_MAX, "%s/%s/", p, repository_path);
@@ -1052,9 +1071,8 @@ static void init_paths()
debug(DEBUG_STATUS, "strip_path: %s", strip_path);
}
-static CvsFile * parse_file(const char * buff)
+static CvsFile * parse_rcs_file(const char * buff)
{
- CvsFile * retval;
char fn[PATH_MAX];
int len = strlen(buff + 10);
char * p;
@@ -1129,6 +1147,28 @@ static CvsFile * parse_file(const char *
debug(DEBUG_STATUS, "stripped filename %s", fn);
+ return build_file_by_name(fn);
+}
+
+static CvsFile * parse_working_file(const char * buff)
+{
+ char fn[PATH_MAX];
+ int len = strlen(buff + 14);
+
+ /* chop the "LF" */
+ len -= 1;
+ memcpy(fn, buff + 14, len);
+ fn[len] = 0;
+
+ debug(DEBUG_STATUS, "working filename %s", fn);
+
+ return build_file_by_name(fn);
+}
+
+static CvsFile * build_file_by_name(const char * fn)
+{
+ CvsFile * retval;
+
retval = (CvsFile*)get_hash_object(file_hash, fn);
if (!retval)
--
1.4.0
^ permalink raw reply related
* Re: git-cvsimport doesn't quite work, wrt branches
From: Yann Dirson @ 2006-06-15 7:18 UTC (permalink / raw)
To: Keith Packard
Cc: Linus Torvalds, Jim Meyering, Git Mailing List, Matthias Urlichs,
Pavel Roskin
In-Reply-To: <1150224411.20536.79.camel@neko.keithp.com>
On Tue, Jun 13, 2006 at 11:46:51AM -0700, Keith Packard wrote:
> Yeah, we've got
>
> git-cvsimport
> cvsps
> cvs rlog
> ,v files
>
> cvs rlog is designed to 'represent' the history of the repository to
> users.
I wouldn't exactly call that "history of the repository" :)
Are you thinking about any particular information from the ,v files,
that rlog fails to expose ? That is, wouldn't be possible to do a job
similar to what parsecvs does, with remote support ?
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Autoconf/Automake
From: Yann Dirson @ 2006-06-15 7:24 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1150324030.23268.12.camel@dv>
On Wed, Jun 14, 2006 at 06:27:10PM -0400, Pavel Roskin wrote:
> Is there any interest in converting the build system used by git to
> Autoconf and Automake? The ad-hoc configuration in Makefile is getting
> too big. As for nice features like remembering $prefix, wouldn't it be
> better to add them to Automake instead of limiting them to just one
> project?
Since there are many people objecting to autotools, what about using
Jam instead ? It has the advantage of being designed to be
cross-platform, and should have all the features we would need for *git.
When compared to autotools, it rather takes the place of automake, and
can also be use together with autoconf (or any non-make-specific
replacement you can name) if there is a need for it.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH for cvsps] Handle cvs repo with modules
From: Yann Dirson @ 2006-06-15 7:34 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git, cvsps
In-Reply-To: <200606151249.17518.lan@academsoft.ru>
On Thu, Jun 15, 2006 at 12:49:17PM +0700, Alexander Litvinov wrote:
> Parse 'Working file' lines from cvs log output. This alow to work with cvs repos
> with modules. To enable this you need to add --no-rlog to cvsps command line args.
>
> This patch was made to import such repo into git. But git-cvsimport can't load such data.
Thanks, applied (with --whitespace=strip).
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-15 7:35 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: GIT list
In-Reply-To: <200606150921.34690.lan@academsoft.ru>
On Thu, Jun 15, 2006 at 09:21:34AM +0700, Alexander Litvinov wrote:
> Your master branch is not compilable. This is the fix for it.
Right, it was fixed already.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Recent stuff Every man wishes it.
From: Erika @ 2006-06-15 8:19 UTC (permalink / raw)
To: git
Good day dear Sir,
Have more success with women and impress them with your power and stamina in bed
You are just a couple of clicks away from our great prices and handy shipment
Unique offers on most recognized and famous brands on Earth.
Find what you need here: http://www.kissyii.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* Hot'n'new I think, yes.
From: Rickie @ 2006-06-15 8:31 UTC (permalink / raw)
To: glenn
Happy day to you! ;)
Masculine performance has never been so easy to increase with these products
Low prices, handy delivery, everything for your convenience.
World famous brands which keep men happy all over the world
Check up here: http://www.lutetiaaj.com
We thank you for being our customer!
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Matthias Lederhofer @ 2006-06-15 9:26 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606141438u7d7b59e1ra68bc23e2e926290@mail.gmail.com>
> Either GIT-CFLAGS or GIT-BUILD-FLAGS,
> whichever is shorter :-)
I would not take GIT-CFLAGS because there is an environment variable
used by make named CFLAGS and means something else.
What is the target test-prefix-change good for? Should it really be
included?
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Yakov Lerner @ 2006-06-15 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <E1Fqo70-0003pZ-PU@moooo.ath.cx>
On 6/15/06, Matthias Lederhofer <matled@gmx.net> wrote:
> > Either GIT-CFLAGS or GIT-BUILD-FLAGS,
> > whichever is shorter :-)
>
> I would not take GIT-CFLAGS because there is an environment variable
> used by make named CFLAGS and means something else.
What is your preference for this filename ? Is GIT-BUILD-FLAGS
better ? GIT-FLAGS ? Other ?
GIT-CFLAGS is filename here, whereas $(CFLAGS) is variable.
Maybe writing it the filename ./GIT-CFLAGS would
emphasize betterthat it's not make variable, but a filename ?
> What is the target test-prefix-change good for? Should it really be
> included?
The purpose of 'test-prefix-change' is to check that there are no
missing GIT-FLAGS as prerequisite which would result in broken install
if prefix changed between 'make' and 'make install'. The
'make test-prefix-change' would catch it if GIT-FLAGS happened
to be missing in some places that if substantially dependent of $prefix.
Yakov
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Santi @ 2006-06-15 11:26 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <0J0V00LDT7B9BU00@mxout2.netvision.net.il>
Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
> Many times, I mistakenly used 'make prefix=... install' where prefix value
> was different from prefix value during build. This resulted in broken
> install. This patch adds auto-detection of $prefix change to the Makefile.
> This results in correct install whenever prefix is changed.
I do this each time I install packages from source. I keep them with
"stow" and the usual sequence is:
make prefix=/home/santi/usr
make install prefix=/home/santi/usr/stow/git
cd /home/santi/usr/stow/
stow -v git
so with this auto-detection I'll compile some programs twice.
Santi
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Yakov Lerner @ 2006-06-15 11:40 UTC (permalink / raw)
To: Santi, git
In-Reply-To: <8aa486160606150426q19b0a661s@mail.gmail.com>
On 6/15/06, Santi <sbejar@gmail.com> wrote:
> Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
> > Many times, I mistakenly used 'make prefix=... install' where prefix value
> > was different from prefix value during build. This resulted in broken
> > install. This patch adds auto-detection of $prefix change to the Makefile.
> > This results in correct install whenever prefix is changed.
>
> I do this each time I install packages from source. I keep them with
> "stow" and the usual sequence is:
>
> make prefix=/home/santi/usr
> make install prefix=/home/santi/usr/stow/git
> cd /home/santi/usr/stow/
> stow -v git
>
> so with this auto-detection I'll compile some programs twice.
I'm not familiar with stow. Does stow create some kind of symlinks from
/home/santi/usr/stow/git to home/santi/usr ? If so, why can't you
use prefix=/home/santi/usr/stow/git both in 'make' and in 'make install' ?
Would this work ?
BTW, is it possible to have git use argv[0] to automatically determine
the executable_dir without compiled-in paths ?
Yakov
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Santi @ 2006-06-15 12:49 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0606150440l544455c7r5c52609b360d0f74@mail.gmail.com>
2006/6/15, Yakov Lerner <iler.ml@gmail.com>:
> On 6/15/06, Santi <sbejar@gmail.com> wrote:
> > Wed, 14 Jun 2006 22:26 +0300, Yakov Lerner <iler.ml@gmail.com>:
> > > Many times, I mistakenly used 'make prefix=... install' where prefix value
> > > was different from prefix value during build. This resulted in broken
> > > install. This patch adds auto-detection of $prefix change to the Makefile.
> > > This results in correct install whenever prefix is changed.
> >
> > I do this each time I install packages from source. I keep them with
> > "stow" and the usual sequence is:
> >
> > make prefix=/home/santi/usr
> > make install prefix=/home/santi/usr/stow/git
> > cd /home/santi/usr/stow/
> > stow -v git
> >
> > so with this auto-detection I'll compile some programs twice.
>
> I'm not familiar with stow. Does stow create some kind of symlinks from
> /home/santi/usr/stow/git to home/santi/usr ?
It makes links from .../usr/ to .../usr/stow/git/, for expample:
$ls -l ~/usr/bin/git
lrwxrwxrwx 1 santi santi 19 2006-06-01 09:42 /home/santi/usr/bin/git
-> ../stow/git/bin/git*
> If so, why can't you
> use prefix=/home/santi/usr/stow/git both in 'make' and in 'make install' ?
> Would this work ?
For the few tests I've made it does works, but it is not the
recommended method from the stow developers, and I suppose they know
better than me.
>
> BTW, is it possible to have git use argv[0] to automatically determine
> the executable_dir without compiled-in paths ?
>
> Yakov
>
^ permalink raw reply
* Re: [PATCH] auto-detect changed $prefix in Makefile and properly rebuild to avoid broken install
From: Alexander Litvinov @ 2006-06-15 13:00 UTC (permalink / raw)
To: Santi; +Cc: Yakov Lerner, git
In-Reply-To: <8aa486160606150549n4b55912ap@mail.gmail.com>
> > If so, why can't you
> > use prefix=/home/santi/usr/stow/git both in 'make' and in 'make install'
> > ? Would this work ?
>
> For the few tests I've made it does works, but it is not the
> recommended method from the stow developers, and I suppose they know
> better than me.
I always use make prefix=/usr/local/stow/git-bla-bla and it works. The only
thing that make break is the case when you install library into such prefix
and it store it in the pkgconfig file. And when you will compile application
it will be build with library paths set to /usr/local/stow/lib/libxyz and not
to /usr/local/lib/libxyz.
But I dont make such big dependences from sources so it works.
^ permalink raw reply
* Re: Autoconf/Automake
From: Alex Riesen @ 2006-06-15 13:31 UTC (permalink / raw)
To: Yann Dirson; +Cc: Pavel Roskin, git
In-Reply-To: <20060615072450.GF7766@nowhere.earth>
Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:
> > Is there any interest in converting the build system used by git to
> > Autoconf and Automake? The ad-hoc configuration in Makefile is getting
> > too big. As for nice features like remembering $prefix, wouldn't it be
> > better to add them to Automake instead of limiting them to just one
> > project?
>
> Since there are many people objecting to autotools, what about using
> Jam instead ? It has the advantage of being designed to be
> cross-platform, and should have all the features we would need for *git.
Except that it is not readily available everywhere, has unreadable
and illogical syntax, and lots of unknown assumptions built in.
We are forced to use that thing at work, and it is mostly hated.
Git already has enough external dependencies (crypto, Python, Perl,
bash, gmake), why create another one?
If we are about to need a configuration system (and I doubt it), may
be we should at least select a system small enough to have it always
in git repo? (yes, as linux kernel configuration system is)
^ permalink raw reply
* Your money, miter box
From: Fidel Peterson @ 2006-06-15 15:08 UTC (permalink / raw)
To: postmaster
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://wlmmii.cadgywage.com/?67747785
=====
answered, and he lifted from the sand and turned east, toward the home
coursograph, I guess you'd call it, that controls the boot and drives it
popular with other birds. Even his parents were dismayed as Jonathan spent
understanding, I guess. Then I calmly explained it to him.
Fletcher Seagull, who loved aerobatics like no one else, conquered
means he's going to kick off soon. He can go right ahead, but without me,
By the time they returned, it was dark. The other gulls looked at
"Is there anyone else after these treasures?"
^ permalink raw reply
* Re: Collecting cvsps patches
From: Yann Dirson @ 2006-06-15 16:25 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Alexander Litvinov, GIT list
In-Reply-To: <1150340912.24184.7.camel@dv>
On Wed, Jun 14, 2006 at 11:08:32PM -0400, Pavel Roskin wrote:
> That said, having non-compilable repository defeats the purpose of
> collecting the patches to cvsps. Shouldn't only compilable patches be
> allowed in the repository?
Right, it is entirely my fault, I guess I got distracted at that time.
I have change the layout of the repo to avoid such mishappenings in
the future. The master branch holds the fixes, and new features or
intrusive fixes go into their own branches (especially since none of
them are complete yet).
Fixes that may need further thought are in the to-check branch.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Autoconf/Automake
From: Yann Dirson @ 2006-06-15 16:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Pavel Roskin, git
In-Reply-To: <20060615133146.GA5794@steel.home>
On Thu, Jun 15, 2006 at 03:31:46PM +0200, Alex Riesen wrote:
> Yann Dirson, Thu, Jun 15, 2006 09:24:50 +0200:
> > Since there are many people objecting to autotools, what about using
> > Jam instead ? It has the advantage of being designed to be
> > cross-platform, and should have all the features we would need for *git.
>
> Except that it is not readily available everywhere, has unreadable
> and illogical syntax, and lots of unknown assumptions built in.
> We are forced to use that thing at work, and it is mostly hated.
Well, being hated is often the fate of tools for which users got no
training, but are forced to used because of a corporate decision.
That does not necessarily mean the tool is bad in itself.
> If we are about to need a configuration system (and I doubt it), may
> be we should at least select a system small enough to have it always
> in git repo? (yes, as linux kernel configuration system is)
The kernel is a beast that is specific enough to need its own build
system, and does not support that many platforms, IIRC. Wrong
example, if you want my opinion :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Autoconf/Automake
From: Linus Torvalds @ 2006-06-15 17:02 UTC (permalink / raw)
To: Yann Dirson; +Cc: Alex Riesen, Pavel Roskin, git
In-Reply-To: <20060615163209.GJ7766@nowhere.earth>
On Thu, 15 Jun 2006, Yann Dirson wrote:
>
> Well, being hated is often the fate of tools for which users got no
> training, but are forced to used because of a corporate decision.
That's one possible reason.
> That does not necessarily mean the tool is bad in itself.
It does not _necessarily_ mean that, but let's face it, it really usually
does.
Too many developers shrug off the "it's hard to use" argument. THEY think
it's fine. THEY think it's "lack of training". THEY think the tools are
fine, and the problem is the user.
THEY are wrong.
Almost every time when a user says "it's hard to use", the user is right.
Sometimes it's a lack of documentation, but quite often it's just that the
tool interfaces are bad.
Oh, I'm sure git has the same problems, but dammit, I think we've tried
very hard to listen to user opinions, and make the things that make them
go "that's hard" be more obvious. All the things that were _possible_ to
do if you did them by hand, that you now can do pretty obviously without
even knowing what it really does. "git commit -a". "git log -p". "git show
<name>", etc etc.
Sometimes the problem space makes the interfaces fundamentally hard. But
sometimes the program itself just makes things ugly and hard, and autoconf
and automake definitely didn't make it easier for users - they were
designed for people who knew fifteen different versions of UNIX, and not
for sane people.
These days, there aren't fifteen different versions of UNIX. There's a
couple, and it's perfectly ok to actually say "fix your damn system and
just install GNU make". It's easier to install GNU make than it is to
install autoconf/automake.
Linus
^ permalink raw reply
* Re: Autoconf/Automake
From: Olivier Galibert @ 2006-06-15 17:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Alex Riesen, Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.64.0606150954430.5498@g5.osdl.org>
On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
> These days, there aren't fifteen different versions of UNIX. There's a
> couple, and it's perfectly ok to actually say "fix your damn system and
> just install GNU make". It's easier to install GNU make than it is to
> install autoconf/automake.
You should be careful to separate autoconf and automake. Autoconf is
not so bad, and you can make clean, maintainable Makefile.in and
config.h.in files with it, because it uses simple substitution. It is
quite useful to detect available librairies when some are optional,
and also to lightly[1] ensure that prefix and friends will stay the
same between make and make install. Also, especially if you hack a
little bit to alias 'enable' and 'with', you get a sane interface to
optional feature selection. Oh, and to seperate compilation
directories too (vpath generation).
OTOH, automake is a BDSM session gone bad. The makefiles it generates
are atrocious and outdated, even buggy on some lesser makes, which is
quite annoying when what you try to build is gnu make.
The worst of the lot is libtool, though. That one explicitely tries
to make your experience as painful as possible. Including, but not
limited to, hiding the files in dot-directories so that you try to run
gdb on a script, relinking at install time, silently removing flags
you want to pass to ld or the compiler because it thinks it knows
better, locking C++ shared libraries to the exact compiler version
that compiled them through the .la file crap, etc.
So, autoconf can be useful. The rest should die.
OG.
[1] As in, you can still override when running make, but if you don't
override anything you'll get the value you passed to configure every
time.
^ permalink raw reply
* Re: Autoconf/Automake
From: Jakub Narebski @ 2006-06-15 18:03 UTC (permalink / raw)
To: git
In-Reply-To: <20060615174833.GA32247@dspnet.fr.eu.org>
Olivier Galibert wrote:
> On Thu, Jun 15, 2006 at 10:02:10AM -0700, Linus Torvalds wrote:
>> These days, there aren't fifteen different versions of UNIX. There's a
>> couple, and it's perfectly ok to actually say "fix your damn system and
>> just install GNU make". It's easier to install GNU make than it is to
>> install autoconf/automake.
>
> You should be careful to separate autoconf and automake. Autoconf is
> not so bad, and you can make clean, maintainable Makefile.in and
> config.h.in files with it, because it uses simple substitution.
[...]
> So, autoconf can be useful. The rest should die.
Does autoconf generate configure script in POSIX shell, or in bash?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox