Permalink
Browse files

changing zlib and nanopass to be pulled as submodules.

  • Loading branch information...
1 parent 2acbfee commit e498a92767ad39248293635165d8cca20bb938a1 @dybvig dybvig committed Apr 26, 2016
Showing with 8 additions and 0 deletions.
  1. +6 −0 .gitmodules
  2. +1 −0 nanopass
  3. +1 −0 zlib
View
@@ -0,0 +1,6 @@
+[submodule "zlib"]
+ path = zlib
+ url = https://github.com/madler/zlib.git
+[submodule "nanopass"]
+ path = nanopass
+ url = https://github.com/nanopass/nanopass-framework-scheme.git
Submodule nanopass added at 221eec
Submodule zlib added at 508932

4 comments on commit e498a92

@david135

It may be helpful to add the line: "ignore = dirty" to the zlib entry, so that 'git status' and 'git diff' don't make noise about the results of building the library. (There may be other solutions, but this seems to work for subprojects that aren't actively being modified.)

@dybvig
Member
dybvig commented on e498a92 May 3, 2016

The root zlib directory should not have been getting dirty since builds are done only in work areas, but it was getting dirty because the workarea script was creating symlinks from the work-area zlib to the root zlib, allowing configure changes in the work-area zlib to propagate through to the root zlib. With this commit, workarea does a recursive copy of zlib to prevent this problem, so ignore = dirty should be unnecessary.

@david135

Looks great. I ended up with a similar solution (it seems to be sufficient to just have workarea copy 'Makefile' instead of linking), but didn't want to suggest tampering with the build process without knowing the trade-offs. Thanks!

@dybvig
Member
dybvig commented on e498a92 May 3, 2016

I've seen zconf.h.cmakein also show up modified. In any case, copying the entire directory is safer and a better precedent for future subprojects.

Please sign in to comment.