[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnu-arch] [bug #5573] includes in multi-tree projects
From: |
nobody |
Subject: |
[Bug-gnu-arch] [bug #5573] includes in multi-tree projects |
Date: |
Wed, 15 Oct 2003 17:58:09 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031010 Galeon/1.3.9 |
=================== BUG #5573: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5573&group_id=4899
Changes by: Christian Thaeter <address@hidden>
Date: Wed 10/15/03 at 23:58 (Europe/Berlin)
------------------ Additional Follow-up Comments ----------------------------
I would like to make an end on this debate.
IMO the current config syntax is flawed because the
'LOCATION REVISION' is quite freeform and not easy to detect/differentiate
from other possible commands.
a better proprosal is some syntax like:
'keyword ARGUMENTS...'
where we can use:
'subproject LOCATION REVISION'
'include CONFIGFILE'
with this we are free to add all kinds of extensions with an uniform syntax in
future! It is much more pleasant for a human to read and edit too.
A problem is that it breaks the current syntax. Some might consider this bad,
but i dont think that this is a showstopper because the configfiles (and tools
which generate them) can be easily upgraded (we can provide --oldcfg switch
until tla 1.2 or so, too). It does not break archives, and tools/tla can ignore
any line which starts with a keyword it doesnt understand.
Next is that I am currently working on my MaLa extension language which
supports the same syntax by default (coincidentally, i swear). That means when
MaLa is finshed and integrated in tla, it will get scripting support and the
config-files become scripts which control multitree projects.
Christian
=================== BUG #5573: FULL BUG SNAPSHOT ===================
Submitted by: cehteh Project: GNU arch -- a revision control
system
Submitted on: Thu 09/25/03 at 19:17
Category: tla Severity: 5 - Major
Bug Group: small feature idea Resolution: None
Status: Open Release:
Fixed Release: Merge Request?: yes -- merge from my
archive
Your Archive Name: address@hidden Archive Location:
http://cehteh.homeunix.org/arch/cehteh000
Assigned to: None
Summary: includes in multi-tree projects
Original Submission: address@hidden/tla--devo--1.1--patch-1
added 'include' directive to multi-tree config files
address@hidden/tla--devo--1.1--patch-2
fixed tracker and somewhat tested
docs at:
http://cehteh.homeunix.org/pipawiki/HowToSetupArch_2fHowToSetupMultiTreeProjects
cya Christian
Follow-up Comments
*******************
-------------------------------------------------------
Date: Wed 10/15/03 at 23:58 By: cehteh
I would like to make an end on this debate.
IMO the current config syntax is flawed because the
'LOCATION REVISION' is quite freeform and not easy to detect/differentiate
from other possible commands.
a better proprosal is some syntax like:
'keyword ARGUMENTS...'
where we can use:
'subproject LOCATION REVISION'
'include CONFIGFILE'
with this we are free to add all kinds of extensions with an uniform syntax in
future! It is much more pleasant for a human to read and edit too.
A problem is that it breaks the current syntax. Some might consider this bad,
but i dont think that this is a showstopper because the configfiles (and tools
which generate them) can be easily upgraded (we can provide --oldcfg switch
until tla 1.2 or so, too). It does not break archives, and tools/tla can ignore
any line which starts with a keyword it doesnt understand.
Next is that I am currently working on my MaLa extension language which
supports the same syntax by default (coincidentally, i swear). That means when
MaLa is finshed and integrated in tla, it will get scripting support and the
config-files become scripts which control multitree projects.
Christian
-------------------------------------------------------
Date: Tue 10/14/03 at 14:17 By: robertc
Ok, a few things have come up in my config-manager experiment that have
relevance.
1) ./ as a path in a config is very useful. As a config can be an arbitrary
file these days, the use of ./ combined with -d to buildcfg can (if allowed to)
pull the top level directory as well.
2) rather than having a single field line for an include, I think that having
the include specified as
<path> <include trigger><config to include>, where path is the normal
./foo/bar; include trigger is the ,,include or whatever prefix to indicate that
an include should occur, and the config to include is, well duh :}. The
included config then has the <path> prefixed to it's paths. This allows nested
configs to pull in the recipe for a sub project to an arbitrary subdir - more
flexability.
-------------------------------------------------------
Date: Mon 10/06/03 at 18:46 By: cehteh
Finally:
2003-10-06 16:42:58 GMT Christian Thaeter <address@hidden> patch-4
Summary:
fixed the config files include directive
Revision:
tla--devo--1.1--patch-4
now named '/include/' instead of 'include'
fixed coding style
using an assoc_table now
split into 2 functions (arch_read_config and arch_read_config_internal)
modified files:
libarch/cmd-cfgcat.c libarch/configs.c libarch/configs.h
Christian
-------------------------------------------------------
Date: Mon 10/06/03 at 02:30 By: miles
I would suggest using `/include' or `/include/', on the theory that directories
in configs should always be relative, and that `/' seems more `obviously
special' than `,', especially for someone not entirely familiar with arch's
naming conventions (and the slash looks nicer too :-).
-------------------------------------------------------
Date: Sun 10/05/03 at 20:57 By: cehteh
Robert Collins made the suggestion to use ',include' since dirnames with
preceeding commas are already junk names and not valid. I will implement that
now and hopefully that will satisfiy all people
Christian
-------------------------------------------------------
Date: Sat 10/04/03 at 19:51 By: cehteh
please don't just say "No, thats bad." without a better suggestion :) ... I
considered a lot of syntax ideas but i still dont have a better one.
It would be quite simple to add a "%include" where "%" is some arbitiary
choosen character, but this could clash if someone names directories in some
weird sense, so it would need some escaping rules .. doh!
"#include" ... as #.. are comments so far .. ranged out, theres very likely
someone out there who started a comment with that.
My first idea was to treat a line which start with whitespaces as include line
(no keyword required) .. but thats also ranged out, not clear enough.
Further in my opinion the parser should not be forgiving on formatting errors
.. that makes it harder for other tools to parse such a files correct, but it
must generate very precise error messages when sometihng is wrong, so that the
user can fix it easily. Btw: currently it is not very good in that area, tried
to postfix a configdir with a "/"? If you dont know that it doenst work you get
some serious problem in tracking it down.
Christian
-------------------------------------------------------
Date: Sat 10/04/03 at 06:02 By: miles
> think this would NOT clash because all managed
> directories should be relative to './'. I would
> rather add code which rejects configs without a
> leading './' and trailing '/' for subdir names. I
> thought we agreed on this on IRC?
> changing 'include' to '%include' or something else
> shouldn't make a problem but is still ambiguous, the
> './' prefix for subdirs is the best way imo.
No. That's bad.
For users, ./ is a no-op; as far as I know, it's part of automatically
generated configs only because of an arbitrary implementation detail; to make
it mandatory would seem arbitrary and annoying. Remember, configs are a
user-interface too, so arch should be forgiving in parsing it.
-------------------------------------------------------
Date: Sat 10/04/03 at 05:29 By: cehteh
.. back from hollyday
>Could you please make some cleanups to this?
Sure
> a rel_table or assoc_table will do just as well.
I need to check that out, i'm still not familar enough with libhackerlab.
>arch_read_config can be a wrapper
>function that calls arch_read_config_internal (a staticly
>declared function) with extra parameters.
Ok, well but:
Currently it semms to be not a problem if libarch is not threadsafe, i had no
time to ask you about future directions, so i made the decision on myself to
make it threadsafe there (yes my patch is not very elegant there). Other
changes *would* require at least one additional user supplied argument
(assoc_table* ?) to keep the state for the current run. Please tell me ur
opinion.
> The particular include syntax is an interesting idea but
> won't quite cut it, i'm afraid. The problem is: what if
> I have a subdir named "include"? The syntax you chose
> might break some existing configs, and will lead to
> confusing errors in future configs.
I think this would NOT clash because all managed directories should be
relative to './'. I would rather add code which rejects configs without a
leading './' and trailing '/' for subdir names. I thought we agreed on this on
IRC?
changing 'include' to '%include' or something else shouldn't make a problem but
is still ambiguous, the './' prefix for subdirs is the best way imo.
Would you allow absolute subdir paths? i think thats a bad idea.
> Minor formatting issues....
Yeah, was in a hurry before hollydays, and ususally i dont use that style.
Cheers Christian
-------------------------------------------------------
Date: Sun 09/28/03 at 00:27 By: tomlord
Could you please make some cleanups to this?
In particular:
There is no need for the type `struct arch_file_list': a
rel_table or assoc_table will do just as well.
The parameters to arch_read_config should not need to
change. Instead, arch_read_config can be a wrapper
function that calls arch_read_config_internal (a staticly
declared function) with extra parameters.
The particular include syntax is an interesting idea but
won't quite cut it, i'm afraid. The problem is: what if
I have a subdir named "include"? The syntax you chose
might break some existing configs, and will lead to
confusing errors in future configs.
Minor formatting issues.... Please:
put a space after `for' but not after the '('.
put spaces around '=' in assignments.
put a space between the function name and the '(' in
function calls. Do not put a space after the '('.
put spaces around the '==' in comparisons -- around all
binary operators in general.
put a blank line between local variable declarations and the
rest of the code in the block
don't put a space before ')' in an `if'
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5573&group_id=4899
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/03
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/04
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/04
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/05
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/05
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/06
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/12
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects, nobody, 2003/10/14
- [Bug-gnu-arch] [bug #5573] includes in multi-tree projects,
nobody <=