Fix bug that causes ignored 'exclude' directive

[bppr]

When building a Package that has one or more Targets specified,
the exclude gets treated as though it's a key of the latest target.
By moving the exclude directive above Target, this bug is fixed.

[kostiakoval]

Great that you have fount that bug. I think it would better to keep a 29_exclude_directory test as it is with no targets and add a new one. That way you could guaranty that both case would work.

//`29_exclude_directory
let package = Package(
     name: "29_exclude_directory",
     exclude: ["FooLib"]

//`30_exclude_directory_with_target
let package = Package(
     name: "29_exclude_directory",
     targets: [Target(name: "FooLib")],
     exclude: ["FooLib"]

[bppr]

Got it. Updated bppr/master with a separate functional test.

[kostiakoval]

The TOML format is basically a hash table with Keys and Values. The order of the operators (exclude or targets first) shouldn't have an impact on the output.
If I move this code to line 116, the test wont pass.

result += "\n" + "exclude = \(exclude)" + "\n"

As other good example switching order for testDependencies and dependencies doesn't have any impact on the app.
It seams (at least for me) that there is an error in TOML Formatting.

[bppr]

The order of the operators (exclude or targets first) shouldn't have an impact on the output

Agreed, it shouldn't -- but it does. I'm not super-familiar with TOML, so I don't know if there's a good way to tell TOML that the key you're adding is not part of the key/value set for a Target, but what ends up happening is that the table for the last target ends up with an exclude key, and not the root Package itself.

[package]
name = "whatevs"
# more TOML here

[[package.targets]]
name = "TargetOne"

[[package.targets]]
name = "TargetTwo"

exclude = ["TargetTwo"]

If that's done, TOML thinks exclude is part of what's specified for "TargetTwo" -- that's the issue that needs to be fixed -- the easiest fix is just to move exclude up so it's not confused with any keys associated with Target, but if we want to dive in and do something else to fix this, I'm all ears.

[bppr]

Also, I've just noticed that if I change the order such that it writes targets first, before dependencies or testDependencies, it does break. In fact, it fails to even bootstrap itself properly. So things, as they stand, are order-dependent in that we can't put anything that is intended to be a key for the top-level package after the target declarations.

[mxcl]

Yeah the exclude needs to be parented with the [package] part.

[mxcl]

Thanks for this, would be good to add a comment to the new test linking here for reference.

[bppr]

Will do.

[bppr]

How's this, @mxcl?