Allow to run make from "main" and "parsers" sub-directories #300
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
masatake
added a commit
that referenced
this pull request
Apr 29, 2015
Allow to run make from "main" and "parsers" sub-directories
|
Thanks. This one is really needed, too. |
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 22, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 22, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
vhda
pushed a commit
to vhda/ctags
that referenced
this pull request
Jul 23, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
toroidal-code
added a commit
to toroidal-code/ctags
that referenced
this pull request
Jul 24, 2015
Summary: This commit fixes ticket universal-ctags#300 (improper handling of ';;' at toplevel) and universal-ctags#355 (error on parsing empty file). But more importantly, it adds support for: proper function recognition (kinda) let rec ... and ... module [rec] M : sig ... end = struct ... end module [rec] M = struct ... end and N = struct ... end Most of these changes required a single-token lookahead, so I added this to all of the parsing functions. It's now used rather prolifically. Function discovery relies upon the assumption that most people write functions like let [rec] my_func a b c = ... or let [rec] my_func () = ... or let [rec] () = ... let [rec] _ = ... Still unsupported are things such as let [rec] my_func = function MyCon1 -> ... | MyCon2 ... let [rec] my_func = fun a b c d -> ... The first would require two-token lookahead, while last would require an n-token lookahead. Although, support _may_ be able to be added by using a 'functionValidation' function similar to constructorValidation. Something to look into.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This tries to address @techee's comment #298 (comment) @techee, does this actually solves your issue?
Note that the code here is particularly adapted for running against #298 (as it asks for
parsers/$@and not$@, e.g. object files in sub-directories), but also work fine on current master, as currently asking for e.g.parsers/go.owill involve the rule.c.oonparsers/go.c, rule that will generatego.o(and not the askedparsers/go.o, but that's what we want).