forked from commonmark/cmark
-
Notifications
You must be signed in to change notification settings - Fork 108
2020/01/03 Merge #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
2020/01/03 Merge #14
Conversation
This file contains hidden or 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
This modifies unescaping in houdini_html_u.c rather than the entity handling in inlines.c. Unlike the other, this approach works also in e.g. link titles.
by inserting an HTML comment. Closes commonmark#317. I think I'll follow up with a change to use fenced code blocks, but this was the minimal fix.
This solves problems with adjacent code blocks being merged.
* build: inline a variable * build: use `LINKER_LANGUAGE` property for C++ runtime Rather than explicitly name the C++ runtime, use the `LINKER_LANGUAGE` property to use the driver to spell the C++ runtime appropriately. * build: use CMake to control C standard Rather than use compiler specific flags to control the language standard, indicate to CMake the desired standard. * build: use the correct variable These flags are being applied to the *C* compiler, check the C compiler, not the C++ compiler. * build: loosen the compiler check This loosens the compiler identifier check to enable matching AppleClang which is the identifier for the Xcode compiler. * build: hoist shared flags to top-level CMakeLists This hoists the common shared flags handling to the top-level CMakeLists from sub-layers. This prevents the duplication of the handling. * build: remove duplicated flags This is unnecessary, `/TP` is forced on all MSVC builds, no need to duplicate the flag for older versions. * build: loosen C compiler identifier check Loosen the check to a match rather than equality check, this allows it to match AppleClang which is the identifier for the Apple vended clang compiler part of Xcode. * build: use `add_compile_options` Use `add_compile_options` rather than modify `CMAKE_C_FLAGS`. The latter is meant to be only modified by the user, not the package developer. * build: hoist sanitizer flags to global state This moves the CMAKE_C_FLAGS handling to the top-level and uses `add_compile_options` rather than modifying the user controlled flags. * build: hoist `-fvisibilty` flags to top-level These are global settings, hoist them to the top level. * build: hoist the debug flag handling Use a generator expression and hoist the flag handling for the debug build. * build: hoist the profile flag handling This is a global flag, hoist it to the top level and use `add_compile_options` rather than modify the user controlled flags. * build: remove incorrect variable handling This seemed to be attempting to set the linker not the linker flags for the profile configuration. This variable is not used, do not set it. * build: remove unused CMake includes
Replace `add_compile_definitions` with `add_compile_options` since the former was introduced in 3.12.
Avoid including the utility once, which should avoid some unnecessary CMake checks, and reduces duplication.
man pages are extremely useful, but are not generally available on Windows. This changes the install condition to check for the Windows cross-compile rather than the toolchain in use. It is possible to build for Windows using clang in the GNU driver.
This uses the CMake mechanism for including the current source and binary directories. This avoids the custom handling for this.
This reduces the work that CMake needs to do to configure the libraries by setting all the properties at once.
Remove the unnecessary execute permission on CMakeLists.txt.
This configures the target to setup the include paths publicly for the library targets in the build interface. This enables uses of the targets in the build tree without having to specify the include directories. This is particularly useful for use in the export targets, but also simplifies the rules for the API tests. The install interface does not need the include directories as `cmark.h` is installed into `include` which is a default include path.
This enables the use of the export targets from the build tree to allow easy use of the CMark library in other projects. Resolves: commonmark#307
CC: @akyrtzi |
@swift-ci please test |
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.
Merge commonmark/cmark from upstream