corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Fwd: Release_0.1
Date Thu, 13 Aug 2015 11:11:26 GMT
---------- Forwarded message ----------
From: jan i <jani@apache.org>
Date: 13 August 2015 at 12:00
Subject: Re: Release_0.1
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org
>


Hi

Sorry for top posting.

Justin have been an enormous help in getting the licenses etc correct,
there was a couple of new things to me.
- If we only link to a third party library and do not include it in the
license, we do not need to mention it anywhere (as is this is no legal
issue)
- I wanted to play fair to our users, and have made a LINK_DEPENDENCY file
- DEVELOPERS got a short description of why these names and not others.

I hope I have just sent the last version to justin for checking and then
get started on the voting process (2 fold, first us, then IPMC).

Are there any special wishes regarding the voting process ?

Please remember a release cannot be vetoed with a -1.

rgds
jan i.


On 10 August 2015 at 05:56, Peter Kelly <pmkelly@apache.org> wrote:

> > 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