Would you mind adding some tests? Also, it'd be nice to have a separate flag for error rather than making the user pipe through perl

yeah i'll try to add some tests, i've never written ruby tests before, but will give it a go.

what would be your preference to turn warnings to errors? separate flag? or change -w to demand an argument, e.g.

synx -w warning Example.xcodeproj
# or
synx -w error Example.xcodeproj

alternative would be to add a new parameter -e:

synx -e Example.xcodeproj

Check out some of the existing specs -- they should be helpful in writing some new ones.

Should we do

synx --flag warn Example.xcodeproj
# same as
synx -f warn Example.xcodeproj

synx --flag error Example.xcodeproj
# same as
synx -f error Example.xcodeproj

are you suggesting we might support other flags in the future, would they be comma-separated?

I think I'm just learning towards warn and error as inputs to a flag rather than flags themselves, since only one or the other should be able to be on at a time. --warn --error wouldn't make sense, thought I supposed most people would be smart enough to know that

@samdods don't use -e, it's already reserved for --exclusion, -e EXCLUSION ignore an Xcode group while syncing :)

imho, --flag, -f warn_OR_error is fine, and it probably only needs to accept one flag.

Yup, with @intelliot on the one flag thing. I'm really excited about this feature, I think that it can actually serve as a great solution to a the Xcode-Plugin request that I keep getting.

I definitely want to merge this omce we make the couple of changes we've discussed, and some tests. A cool future idea would be using xcodeproj (which Synx already uses heavily) to automatically create a run-script build phase for the user in their Xcodeproject to call out to synx, so they don't have to worry about doing it themselves, kind of like Mayday does https://github.com/marklarr/mayday/blob/master/lib/mayday/target_integrator.rb#L14

I'm currently working on the solution (not right this second but it's work in progress)...
I'm using --warn-only and then have --modifier (multi valued), with which you can provide modifiers for other flags. Only modifiers are "warning" or "error" for now (default is "warning"). I think that this is the most versatile solution, in case we need other flags in the future.
Thoughts? I can always scrap what I've done if you don't like it and go with just one --flags warn_OR_error

On 7 Feb 2015, at 08:30, Mark Larsen [email protected] wrote:

Yup, with @intelliot on the one flag thing. I'm really excited about this feature, I think that it can actually serve as a great solution to a the Xcode-Plugin request that I keep getting.

I definitely want to merge this omce we make the couple of changes we've discussed, and some tests. A cool future idea would be using xcodeproj (which Synx already uses heavily) to automatically create a run-script build phase for the user in their Xcodeproject to call out to synx, so they don't have to worry about doing it themselves, kind of like Mayday does https://github.com/marklarr/mayday/blob/master/lib/mayday/target_integrator.rb#L14

—
Reply to this email directly or view it on GitHub.

actually, i've changed it the only flag i'm adding is as follows (i didn't want to use --flags because it might be needed for something more generic in the future):

  option ["--warn-type", "-w"], "warning|error", "show warnings or errors for files whose paths do not match the project structure. Using this option will not make any changes to the project. Use it as an Xcode build phase to alert the developer."

update to the PR will be coming soon

@samdods what is the status of this? I'm hoping to use this in a project I'm working on!

Haven't had any time to work on it recently. Can't make any promise when I'll complete it. You could download my fork and rake build/install that, although I'm not even sure if it's in a state that works as expected.

On 11 Mar 2015, at 23:23, Colin Tremblay [email protected] wrote:

@samdods what is the status of this? I'm hoping to use this in a project I'm working on!

—
Reply to this email directly or view it on GitHub.

@samdods just for the record, this has huge value for anyone looking to enforce repo file structure. It allows pre-receive hooks at much more. I would definitely appreciate it if this functionality is available with the next sync release!

yeah this is a great feature is anyone picking this up?

@marklarr @samdods I'd actually like to pick this up, if there's still nothing available like it. I'm interested in using Synx to enforce file structure matching xcodeproj group structure in a pre-commit hook.

Any updates I should know about since December 2015?