corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Release_0.1
Date Mon, 10 Aug 2015 03:56:48 GMT
> On 10 Aug 2015, at 1:00 am, jan i <jani@apache.org> wrote:
> 
> On 9 August 2015 at 19:42, Dennis E. Hamilton <dennis.hamilton@acm.org>
> wrote:
> 
>> The exclusion of build-tool artifacts is more a safeguard against
>> developers doing IDE editing and testing in the tree in inappropriate
>> places, just like the "~" case but more serious.
>> 
> a lot more serious....e.g. a .sln file can only be there if you ask cmake
> to generate it.
> 
> 
>> 
>> I eliminated those likely suspects because GitHub has found it important.
>> I included it in .gitignore as a precautionary reminder.  I did not bring
>> back in all other cases.  But I know Visual Studio builds are sort of
>> encouraged for Windows.
>> 
>> I am not attached to doing that.  It does strike me as harmless though.
>> 
> I feel strongly about it, because you supress a signal that the system is
> being build wrongly.
> Visual studio uses the sln directory (and subdirs) for all its files (with
> our current cmake), so it is a real error if we see them elsewhere,
> something the developer should see and not be silently ignored.
> 
> I read peter as also being against having them in .gitignore, so if you
> are not attached to it, please revert that part (together with iconv.txt).

Yes; CMake is supposed to be run outside of the source directory. If you run it inside the
source directory, and do a “git status”, then these will show up as “untracked files”.
These serve as an easy-to-see warning.

In by build directory (inside the root of the repository), with files generated for Xcode,
here’s what I currently have:

CMakeCache.txt
CMakeFiles/
CMakeScripts/
Corinthia.build/
Corinthia.xcodeproj/
DerivedData/
DocFormats/
cmake_install.cmake
consumers/
experiments/

If I run cmake -G Xcode . inside the root of the repository, without yet building anything,
here’s what I see in git status:

On branch master
Your branch is up-to-date with 'apache/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	CMakeCache.txt
	CMakeFiles/
	CMakeScripts/
	Corinthia.xcodeproj/
	DocFormats/api/cmake_install.cmake
	DocFormats/cmake_install.cmake
	DocFormats/core/cmake_install.cmake
	DocFormats/filters/latex/cmake_install.cmake
	DocFormats/filters/odf/cmake_install.cmake
	DocFormats/filters/ooxml/cmake_install.cmake
	DocFormats/platform/cmake_install.cmake
	DocFormats/unittest/cmake_install.cmake
	cmake_install.cmake
	consumers/dfconvert/src/cmake_install.cmake
	consumers/dftest/src/cmake_install.cmake
	consumers/dfutil/src/cmake_install.cmake
	experiments/flat/src/cmake_install.cmake

If I instead run cmake -G “Unix Makefiles”, there are even more - about 40.

So using the source directory as the build directory gets really messy - I suspect there’d
be even more files show up after a successful build, but I’ve just found the Unix Makefiles
build is currently not working (at least on my machine; I’ll look into this shortly). We
want to explicitly discourage people from trying this, and make it clear that a separate directory
should be used instead.

Also, everyone uses different subdirectories for build outputs. I use “build” and “winbuild”
for OS X and Windows. Jan uses “build.win32”, “build.win64”, “build.ubuntu”, and
“build.xcode”. Others will presumably use different names again.

I also have a bunch of .flat and .exp files that I use for temporary testing that I want in
the directory but aren’t supposed to be in the repository. They shouldn’t be in .gitignore
because they’re my personal temporary names.

So I think it’s a bad idea to include Vistual Studio/XCode project files and the like in
.gitignore.

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message