Web lists-archives.com

Re: [Mingw-msys] HAVE_SETMODE -- rethinking -> GnuWin32+MSYS

On 3/18/2011 5:51 PM, Chris Sutcliffe wrote:
> On 18/03/2011 5:23 PM, Charles Wilson wrote:
>> On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:
>>> --with-features=huge
>> Doesn't this mean that msys-perl is now required? Or is that just if you
>> want to use the (pseudo)embedded perl functionality?
> I don't believe so, :version reports '-perl':

Right; perl support requires to be explicitly enabled, even if +huge.

>> BTW, it's usually been the convention that msys packages are configured
>> with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
>> the enforced MSYS mount structure.  I'm not sure it makes a difference
>> -- but it costs nothing so I'm not really sure why it should be changed.
> I tried that at first, but the DESTDIR captures '/usr' in the tarball,
> so I dropped it to '/'.  I suppose I could filter out '/usr' when
> creating  the tarball.

Yep, that's the way we've been doing them:
  make install DESTDIR=/foo
  (cd /foo/usr && tar -cvf ...)

>> In the FRS release area, there's no release notes.
>> There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt
>> either, so that's probably why.
> Fair enough, I'll capture my build instructions there.

Yep...that makes it easier to keep notes like
  + Remember to make sure the bin/* hardlinks to vim.exe
    all have .exe extensions...

>> Frankly, I'm surprised that you seem to have worked *harder* -- manually
>> installing 37 different patches (1-100, +101..138) to generate the -src
>> package, and apparently manually typing commands to create the various
>> .tar.lzma's -- than simply re-using and editing the existing automated
>> structure from vim-7.2-2-src's msys-build-vim script.
> Actually I didn't work that hard at all, I simply pulled that latest
> source from Mercurial, so no manual patching was required.

Ah...which is yet another reason why you couldn't automate this *inside
an msys shell*.  We don't provide mercurial.

>> So...I suggest that for the next revision, whenever anybody feels like
>> it or gets around to it, restore some of these items like release notes
>> and automated build scripts.
> I agree with the release notes, but I'm not sure about the automated
> build scripts, since I have never supplied them before with any other
> package I've provided (I seem to remember having this discussion before
> but can't seem to find a reference to it).

Well, that's why it is a suggestion, not a command. (I'll point out
again that w32api and mingwrt are "special"... and gdb.  Dang, gdb.
Well, if EVER there was an msys package that could use some
documentation on how to get the darned thing built and working on msys,
it's gdb...

The main reason for *automation* -- as opposed to documentation -- is to
*specifically* allow other maintainers to come in and easily reproduce
your work, in the event of a security fix, bus+Linus event, etc.  And,
since documentation always gets out of date, automated build scripts
force an eat-your-own-dogfood mentality.

Without such a script (or, if an earlier script already exists but one
ignores it), then anyone attempting to rescue a floundering package
basically has to start from scratch -- and previous lessons learned get
forgotten. (Case in point: the .exe thing was a bug fix at some point,
and was captured in the build script as part of the msys_install() function:

  pushd ${instdir}${PREFIX}/bin 2>/dev/null
  for f in ex rview rvim view vimdiff
    if [ -e $f ]
      rm -f $f
    if [ -e $f.exe ]
      rm -f $f.exe
    ln vim.exe $f.exe
  popd 2>/dev/null

Also, oould you speak more to the "vim-7.3 builds out of the box on
msys" thing?  We don't typically send MSYS patches upstream; we
typically #define __CYGWIN__ and adapt as necessary.

We don't normally #define __CYGWIN32__ and your ./configure recipe
didn't mention CFLAGS settings.

While cygwin's gcc defines that old macro -- and lots of vim source is
(was?) conditionalized on the __CYGWIN32__ variant.  Hence the
So unless you added both -D__CYGWIN__ -D__CYGWIN32__ to CFLAGS, or
upstream (finally) switched to all __CYGWIN__ and no __CYGWIN32__ AND
you added -D__CYGWIN__, or upstream magically added also #if
defined(__MSYS__) conditionals...I'm concerned.  Unless something fancy
is happening behind the scenes, msys-vim won't be compiled with any of
the necessary *cygwin*izations.

(Oh, and vim-7.2 relies on a particular posix-conforming behavior of
fchdir IF fchdir() exists.  MSYS has fchdir() but it is broken in a
particular case, which vim doesn't like.  Hence, 7.2-2 does this:

  ### avoid fchdir, force termcap
  export ac_cv_func_fchdir=no
  export vim_cv_terminfo=no

prior to running configure. (Looks like the terminfo/termcap thing isn't
necessary with 7.3, but I bet the other is...

	$ objdump -p vim.exe | grep fchdir

Hmm.  Maybe not.

Anyway, did you run the vim testsuite?

I'm not saying you HAVE to do a build script, nor that if you do that it
must look like the one from 7.2.  Or that you should bother right now,
while trying to get 7.3 done.  (Maye for 7.4...)

It's just...why not use the script?  It's already there and just needs
tweaking for 7.N+1 most likely...

My build scripts are structured like this, BTW:

... setup and var defs ...
... function definitions ...
# and nothing /actually happens/ until the very end,
# where the functions are invoked one after another:


This makes for (relatively) easy step-wise operation, by commenting out
various lines at the end of the script.  That gets tricky vs.
msys_package().  I tend to do this:

# msys_conf_prep
# msys_conf
# msys_build
# msys_check
# msys_install
sleep 30

And then, after invoking the script for my piecewise 'package' step, I
edit the script from another window -- while the original window is
stuck in the sleep 30 -- to un-comment-out the lines and remove the
sleep.  This way the package gets a do-it-all version of the build script.

/that's/ a bit clunky, but I didn't want to add an arg-parsing loop to
the build script. At least not until I go /all out/ and finish the
msysport project...


Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
Mingw-msys mailing list