[Bug-gnu-arch] [bug #5573] includes in multi-tree projects

[nobody]

=================== BUG #5573: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5573&group_id=4899

Changes by: Miles Bader <address@hidden>
Date: Sat 10/04/2003 at 13:02 (Asia/Tokyo)

------------------ Additional Follow-up Comments ----------------------------
> 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.





=================== BUG #5573: FULL BUG SNAPSHOT ===================


Submitted by: cehteh                  Project: GNU arch -- a revision control 
system
Submitted on: Fri 09/26/2003 at 02:17
Category:  tla                        Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Feedback                     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: Sat 10/04/2003 at 13: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/2003 at 12: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/2003 at 07: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/