source globbing

[Erik Smith]

Is there any way to say sources = glob([*.cc]) or must I list all sources explicitly?

[James Robinson]

There's no globbing, list all sources explicitly.

- James

[Dirk Pranke]

Following up on what James wrote, the reason there isn't any source globbing is that there's no good way to reliably detect when the glob would return new results and you need to rebuild; the closest you can usually get is to look at the timestamps for modifications on the containing directory, but that doesn't tend to be reliable.

If you are 100% certain that you want globbing anyway, you can use exec_script() to call out to something that'll do the glob for you.

-- Dirk

[Erik Smith]

Good to know, although it seems like directory state (both filenames and content hashes) could be e kept to accomplish this, but I'm guessing that is not part of the design as it is ninja's role to detect changes.

erik

[Dirk Pranke]

You could potentially do it by hash. Ninja doesn't currently do filename or directory hashing, as it would significantly slow things down for large projects, and you're correct that it would be ninja that would have to check things.

One can imagine adding the feature to Ninja, but so far there's never been sufficient demand for it.

Often people are against using globs for other reasons, because it can make it easier to accidentally include files that you didn't mean to include.

-- Dirk

[Ben Boeckel]

On Wed, Oct 04, 2017 at 11:09:08 -0700, Dirk Pranke wrote:
> Following up on what James wrote, the reason there isn't any source
> globbing is that there's no good way to reliably detect when the glob would
> return new results and you need to rebuild; the closest you can usually get
> is to look at the timestamps for modifications on the containing directory,
> but that doesn't tend to be reliable.

Note that if you're trying to build in the middle of a conflict
resolution (something I do occasionally at least), Git will drop the
conflict files with the same extension as the base file, so you may end
up compiling conflict files as well with a glob. Generally, globs aren't
the best idea for collecting source files.

--Ben

[Erik Smith]

I'm wondering if it makes sense for gn to display unreferenced sources (in directories that are referenced) as a utility.   It wouldn't be hard to write a script to do that, but it would be nice if were integrated into gn along with all of the existing diagnostic functions.

erik

On Wednesday, October 4, 2017 at 11:09:30 AM UTC-7, Dirk Pranke wrote:

[Brett Wilson]

The problem is this would also trigger for platform-specific files that are excluded due to source expansions, or appear only in if blocks not taken in a given build. Some projects may not have these, but Chrome has thousands, making such a utility useless for us.

Brett

[Primiano Tucci]

As a more general comment, globbing is generally not a great idea for any project based on git. Git leaves untracked files around by design (e.g., when adding/removing things to gitignore and switching branches, when checking out a branch while having new local files not added to the index etc.).

There was a time where the Chrome for android build was doing globbing of .java files and that caused a large amount of subtle bugs for this (and related) reason.  That was... not a great idea.

--
You received this message because you are subscribed to the Google Groups "gn-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+unsubscribe@chromium.org.

[Erik Smith]

I agree that explicitly listing files is a more cautious approach.   I was suggesting just a diagnostic function that would list unreferenced source files and only for directories where source is referenced explicitly.  I think that would exclude a lot of the ignored files that might be listed.   Also git is very flexible with local branching as a way to isolate work in progress.  Another option is just to have gn output pure source paths so that another tool could inspect directories more easily.     As for glob, it's in bazel & buck, so it appears it's being used at scale.  It does make the maintenance of the build scripts simpler at the cost of unintended source being compiled.

erik

To unsubscribe from this group and stop receiving emails from it, send an email to gn-dev+un...@chromium.org.

[Clark Kent]

i would like to do this but for libs instead, like    libs [ {LIB_PATH}/*.so ] # link against all .so files build by a previous gn build

[Clark Kent]

eg

gn -C out/A libs

# unable to depend on A since both A and B have duplicate

# declare_args entries

gn -C out/B main # libs [ {OUT}/A/*.lib ]

[Brett Wilson]

Sorry, there is no way to do this.