Hi hauptmech, thanks for your feedback! See below...

On Sun, Nov 29, 2015 at 7:55 PM, hauptmech <[email protected]> wrote:

>
> The naming of files used by tup are inconsistent and difficult to
> remember. Having to look at the manual everytime I've been away from tup
> for a while will be annoying. Here's what I would change:
>
> ini files....
> 1) just call it tup.ini everywhere. Easy to remember and correct syntaxt
> highlighting on all systems.
>

What exactly do you mean by "it"? Just the current Tupfile.ini? Or also the
options files (.tup/options and such)? From your comment later about
variants it sounds like you might also mean tup.config, but I'm not sure of
the scope here.


> 2) ~/.config/tup/ might be a better location than ~/.
>

Ahh, I wasn't aware of that. That looks reasonable to me.


>
> root directory...
> The vestigil Tupfile.ini feels a bit silly. I'd rather something
> different. Maybe a .tuproot so I don't have to look at it. Maybe a .tup
> directory with only an empty tup.ini.  Maybe this is an unecessary feature.
> Maybe as you scan upward towards "/." the highest directory with a Tupfile
> is your root for the first build.
>

There is some ongoing discussion about this in
https://github.com/gittup/tup/issues/132. Maybe we should open a new issue
for this and get some ideas together.

Looking for the highest-level .tup directory sounds somewhat reasonable,
but we'd have to be careful since we don't want users to commit their
.tup/db file into source control. Maybe we could change the auto-generated
.gitignore file to ignore .tup/db (and other files) instead of .tup, though.


>
> Tupfile & Tuprules.tup...
> *.tup works great. Tools (and developers) don't need to look inside to
> figure out what it's for.
> Tupfile -> build.tup, default.tup, tup.tup, fuk.tup ... anything.tup
> (Build.tup)
>

"Tupfile" isn't so different from "Makefile" - IMO it's pretty
straightforward to look for both Tupfile and *.tup when applying tup
syntax. Eg in vim:

au BufNewFile,BufRead Tupfile,*.tup setf tup


> Variants...
> Again, tup.ini everywhere you use a tup config file.
>

The tup.config file isn't an ini file though, it's supposed to be
compatible with the kernel's .config file generated by kconfig.


> include_rules...
> There's lots of times when you are digging around files and either don't
> know, or have forgotten, the syntax. It can help to explicitly list the
> file.
>
> include_rules Tuprules.tup
>
> It makes it easier start poking around to figure things out for those of
> us that prefer sticking forks in lightsockets than reading the manual.
> _rules might mislead someone to thing that the format is different...
>
> include_all Tuprules.tup
>

That seems like a reasonable change. Though the Lua parser (and the future
Python parser) include the rules automatically, which means those filenames
are fixed (eg: Tuprules.lua). Is there a benefit to having projects specify
their own filename for Tuprules.tup?


> If you think any of the tweaks above are worth implementing, I'm happy to
> issue a pull request.
>
>
Thanks! I think re-opening the Tupfile.ini / how-do-we-auto-init discussion
is worthwhile. It may be a good idea to revisit the filenames that tup uses
as well. If/when I add the python parser, tup will be looking for Tupfile,
Tupfile.lua, Tupfile.py, Tuprules.tup, Tuprules.lua, Tuprules.py,
tup.config, Tupdefault, Tupdefault.lua, Tupdefault.py, and Tupfile.ini (I
think that's all of them). Seems a bit excessive when you write them out :)

Changing filenames and such will likely be backward-incompatible changes.
However, it's likely that the v0.8.0 release will be backward incompatible
anyway, so that might be a good time to introduce these kinds of changes.

-Mike

-- 
-- 
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to