Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up[stdlib] Initial FreeBSD port. #713
Conversation
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dcci
Dec 21, 2015
Member
This continues the discussion in #664. I wasn't able to update that request which was closed. I'll try to improve my git foo in the future to avoid similar issues.
|
This continues the discussion in #664. I wasn't able to update that request which was closed. I'll try to improve my git foo in the future to avoid similar issues. |
gribozavr
reviewed
Dec 21, 2015
| /// | ||
| /// It's not named just FreeBSD libc so that it doesn't conflict in the event of a | ||
| /// future official FreeBSD libc modulemap. | ||
| module SwiftGlibc [system] { |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 21, 2015
Collaborator
SwiftGlibc?
I almost feel like this file should be generated with gyb for both platforms from the same source... Gyb supports substitutions for @GLIBC_INCLUDE_PATH@.
Do you think this would make sense?
gribozavr
Dec 21, 2015
Collaborator
SwiftGlibc?
I almost feel like this file should be generated with gyb for both platforms from the same source... Gyb supports substitutions for @GLIBC_INCLUDE_PATH@.
Do you think this would make sense?
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 21, 2015
Collaborator
Take a look at how we handle UnicodeExtendedGraphemeClusters.cpp.gyb as an example.
gribozavr
Dec 21, 2015
Collaborator
Take a look at how we handle UnicodeExtendedGraphemeClusters.cpp.gyb as an example.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dcci
Dec 21, 2015
Member
About the first question, yes, I kept the Glibc name around in the hope we can rename that to something more generic in the future -- Libc maybe? (but I preferred to limit the churn in this commit).
About the latter -- I think it definitely makes much more sense to have a machine generating it for us. I think it also makes sense to do that first -- what's your idea?
dcci
Dec 21, 2015
Member
About the first question, yes, I kept the Glibc name around in the hope we can rename that to something more generic in the future -- Libc maybe? (but I preferred to limit the churn in this commit).
About the latter -- I think it definitely makes much more sense to have a machine generating it for us. I think it also makes sense to do that first -- what's your idea?
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 22, 2015
Collaborator
There isn't documentation, but you can look at *.gyb files in the source to look up the syntax. As input, gyb accepts text files with Python code in special blocks (either %-lines or %{ ... }% blocks) and ${} substitution expressions.
I think it also makes sense to do that first -- what's your idea?
I'm OK with this happening in order that is easier for you, as long as we arrive at a maintainable codebase with low duplication :)
gribozavr
Dec 22, 2015
Collaborator
There isn't documentation, but you can look at *.gyb files in the source to look up the syntax. As input, gyb accepts text files with Python code in special blocks (either %-lines or %{ ... }% blocks) and ${} substitution expressions.
I think it also makes sense to do that first -- what's your idea?
I'm OK with this happening in order that is easier for you, as long as we arrive at a maintainable codebase with low duplication :)
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 22, 2015
Collaborator
And of course there is ./utils/gyb.py --help, somehow forgot about that.
gribozavr
Dec 22, 2015
Collaborator
And of course there is ./utils/gyb.py --help, somehow forgot about that.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 21, 2015
Collaborator
@dcci Thank you, I like this direction a lot!
I think you might want to adjust this line so that the library name is libc on FreeBSD:
add_swift_library(swiftGlibc
Also, the module name is inferred from the first source file name. You might need to add some CMake plumbing to allow passing down an explicit module name.
|
@dcci Thank you, I like this direction a lot! I think you might want to adjust this line so that the library name is Also, the module name is inferred from the first source file name. You might need to add some CMake plumbing to allow passing down an explicit module name. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gribozavr
Dec 25, 2015
Collaborator
@dcci Just let me know if you want to merge this as is, and refactor later.
|
@dcci Just let me know if you want to merge this as is, and refactor later. |
gribozavr
self-assigned this
Dec 25, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dcci
Dec 25, 2015
Member
Let's go for merging as is if you dont mind. I'll refactor immediately after the end of the christmas break.
|
Let's go for merging as is if you dont mind. I'll refactor immediately after the end of the christmas break. |
added a commit
that referenced
this pull request
Dec 25, 2015
gribozavr
merged commit a954ebe
into
apple:master
Dec 25, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
@dcci Merged, thank you! |
dcci commentedDec 21, 2015
Dmitri, All the duplication in the overlay code is now gone. Only the module map is duplicated but I'm not too worried about that (would like to hear your opinion). Also, for now, FreeBSD libc is not-entirely-correctly called Glibc -- but I think a renaming can be done later (maybe it should be called Libc?)
Thanks!
Davide