swift without markup/cmark


(Jon Rafkind) #1

I would like to build swift without support for its markup feature, and in turn leave out the cmark dependency. It looks like markup is used in a few places, such as AST/DocComment.cpp, a few files in IDE/, and PrintAsObjC/PrintAsObjC.cpp.

My initial guess to accomplish this is a new cmake variable, WANT_MARKUP, could be added that provides the define -DWANT_MARKUP, and the various code paths that use the Markup stuff can check for it using an #ifdef.

If I attempted such a thing would it have a chance to be accepted as a patch?

···

--


(Dmitri Gribenko) #2

In general we try to limit the number of build configurations we
support. What is the motivation for this one? cmark is a small
library, as compared to, say, LLVM.

Dmitri

···

On Fri, Jan 8, 2016 at 10:36 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org> wrote:

I would like to build swift without support for its markup feature, and in turn leave out the cmark dependency. It looks like markup is used in a few places, such as AST/DocComment.cpp, a few files in IDE/, and PrintAsObjC/PrintAsObjC.cpp.

My initial guess to accomplish this is a new cmake variable, WANT_MARKUP, could be added that provides the define -DWANT_MARKUP, and the various code paths that use the Markup stuff can check for it using an #ifdef.

If I attempted such a thing would it have a chance to be accepted as a patch?

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Jon Rafkind) #3

I will be distributing swift as part of a commercial application, and have to disclose all third party libraries due to the open source requirements. The fewer components I have to deal with the better.

Also, I routinely have to mess with the swift build system to get it to find the cmark headers. In the most recent build I did I had to copy the cmark headers to lib/Markup, because Markup.cpp directly tries to #include "cmark.h", but cmake does not have a variable to specify the location of the cmark include directory, it only has one for the lib directory.

···

On 01/08/2016 12:51 PM, Dmitri Gribenko wrote:

On Fri, Jan 8, 2016 at 10:36 PM, Rafkind, Jon via swift-dev <swift-dev@swift.org><mailto:swift-dev@swift.org> wrote:

I would like to build swift without support for its markup feature, and in turn leave out the cmark dependency. It looks like markup is used in a few places, such as AST/DocComment.cpp, a few files in IDE/, and PrintAsObjC/PrintAsObjC.cpp.

My initial guess to accomplish this is a new cmake variable, WANT_MARKUP, could be added that provides the define -DWANT_MARKUP, and the various code paths that use the Markup stuff can check for it using an #ifdef.

If I attempted such a thing would it have a chance to be accepted as a patch?

In general we try to limit the number of build configurations we
support. What is the motivation for this one? cmark is a small
library, as compared to, say, LLVM.

Dmitri

--


(Dmitri Gribenko) #4

Which system is that? The build works correctly when build-script is used.

Dmitri

···

On Fri, Jan 8, 2016 at 11:30 PM, Rafkind, Jon <jon.rafkind@hpe.com> wrote:

Also, I routinely have to mess with the swift build system to get it to find
the cmark headers. In the most recent build I did I had to copy the cmark
headers to lib/Markup, because Markup.cpp directly tries to #include
"cmark.h", but cmake does not have a variable to specify the location of the
cmark include directory, it only has one for the lib directory.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Jon Rafkind) #5

I've tried on linux and osx. I'm sure the build works with the provided build scripts, but right now I am doing a more traditional build where I build each component, install it to some local place, then reference the local paths in the next component that needs it. This is the typical workflow of many open source projects.

In theory, the build should be independent of the actual paths to dependencies, and instead rely on things such as pkg-config or llvm-config to get the right paths.

···

On 01/08/2016 04:08 PM, Dmitri Gribenko wrote:

On Fri, Jan 8, 2016 at 11:30 PM, Rafkind, Jon <jon.rafkind@hpe.com><mailto:jon.rafkind@hpe.com> wrote:

Also, I routinely have to mess with the swift build system to get it to find
the cmark headers. In the most recent build I did I had to copy the cmark
headers to lib/Markup, because Markup.cpp directly tries to #include
"cmark.h", but cmake does not have a variable to specify the location of the
cmark include directory, it only has one for the lib directory.

Which system is that? The build works correctly when build-script is used.

Dmitri

--


(Dmitri Gribenko) #6

I want to warn you that by doing that you are stepping into
unsupported land, and you might build a compiler that does not work,
or works slowly, and libraries that work slowly or fail in unusual
ways. Please read the last paragraph of `./utils/build-script
--help`.

If you have unusual build requirements, I would strongly recommend to
factor them into build-script.

Dmitri

···

On Sat, Jan 9, 2016 at 2:39 AM, Rafkind, Jon <jon.rafkind@hpe.com> wrote:

I've tried on linux and osx. I'm sure the build works with the provided
build scripts, but right now I am doing a more traditional build where I
build each component, install it to some local place, then reference the
local paths in the next component that needs it. This is the typical
workflow of many open source projects.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/