Automating builds?
Philip Prindeville
of something.
I start by grabbing and unpacking
ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2 and then grab
ftp://ftp.vim.org/pub/vim/unix/../patches/7.1/7.1.[0-9][0-9][0-9] ...
Then I try to apply the patches as:
patch -Np0 -d $vim_src_root < $patch
in sorted numerical order.
Seems to work fine until I hit patch 7.1.003, which applies the file
src/gui_w32.c ... which doesn't exist in the Unix tarball.
What's the workaround?
I could use -s -f to patch... but that's like driving without a
seat-belt. And even with -s, it's still really noisy.
Plus do I want to have only part of a patch be applied? It seems to me
that patches should only be applied atomically (i.e. all files in the
patch, or none at all).
What am I missing?
-Philip
James Vega
> Seems to work fine until I hit patch 7.1.003, which applies the file
> src/gui_w32.c ... which doesn't exist in the Unix tarball.
That's one of the patches with the "(extra)" tag which means you only
need to apply it if you're also using vim-7.1-extra.tar.gz.
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Tony Mechelynck
> I'm trying to automate building Vim from scratch, but I'm running afoul
> of something.
>
> I start by grabbing and unpacking
> ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2 and then grab
> ftp://ftp.vim.org/pub/vim/unix/../patches/7.1/7.1.[0-9][0-9][0-9] ...
>
> Then I try to apply the patches as:
>
> patch -Np0 -d $vim_src_root < $patch
>
> in sorted numerical order.
>
> Seems to work fine until I hit patch 7.1.003, which applies the file
> src/gui_w32.c ... which doesn't exist in the Unix tarball.
>
> What's the workaround?
The workaround I've been using is to get the full Unix+extra+lang sources:
this eliminates rejects, unless there's a patch for a runtime file and you've
been keeping the runtime files up-to-date separately (most of their changes
are not refolected in the official patches).
>
> I could use -s -f to patch... but that's like driving without a
> seat-belt. And even with -s, it's still really noisy.
>
> Plus do I want to have only part of a patch be applied? It seems to me
> that patches should only be applied atomically (i.e. all files in the
> patch, or none at all).
>
> What am I missing?
>
> -Philip
If you keep your runtime files up-to-date separately (e.g. using rsync), as
you should, there will occasionally be a patch for a runtime file for which
you're using some newer version than what the patch expects as input, and the
patch to that file will fail, but you can ignore it and keep the patches to
other files in the same patch. I do the patching by hand when there are new
patches, but patching errors to *.vim or *.txt files don't scare me, because
I'll next (and periodically thereafter) be rsyncing my runtime files with
Bram's, and even if I don't get the new version then and there (because the
rsync server might not yet be updated) I'll eventually get it.
For program source files (*.c, *.h, *.cpp, *.xs, *.pro, Makefile,
configure.in, *.mk... are there others?) I download all three archives to
start with, even though I'm running on Linux, because then there won't ever be
patches to "missing sources"; and "unneeded sources" are not bothersome, they
just won't be compiled when the time comes to run "make". To me, my peace of
mind is worth downloading and updating the full set of sources, even those I
eventually won't be compiling.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
213. Your kids start referring to you as "that guy in front of the monitor."
Philip Prindeville
> Philip Prindeville wrote:
>
>> I'm trying to automate building Vim from scratch, but I'm running afoul
>> of something.
>>
>> I start by grabbing and unpacking
>> ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2 and then grab
>> ftp://ftp.vim.org/pub/vim/unix/../patches/7.1/7.1.[0-9][0-9][0-9] ...
>>
>> Then I try to apply the patches as:
>>
>> patch -Np0 -d $vim_src_root < $patch
>>
>> in sorted numerical order.
>>
>> Seems to work fine until I hit patch 7.1.003, which applies the file
>> src/gui_w32.c ... which doesn't exist in the Unix tarball.
>>
>> What's the workaround?
>>
>
> The workaround I've been using is to get the full Unix+extra+lang sources:
> this eliminates rejects, unless there's a patch for a runtime file and you've
> been keeping the runtime files up-to-date separately (most of their changes
> are not refolected in the official patches).
>
So... is there a tarball that contains everything then?
-Philip
Ben Schmidt
>
> There are 3 tarballs. vim-7.1.tar.bz2, vim-7.1-extra.tar.gz, and
> vim-7.1-lang.tar.gz. The extra tarballs are under the extra directory
> on the ftp server.
Which is a 'no', in case that wasn't clear. To get everything, you need to get the
three tarballs, which are designed to be extracted 'on top of' each other, i.e.
their contents get merged together to obtain the whole set of sources.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Philip Prindeville
>>> So... is there a tarball that contains everything then?
>>>
>> There are 3 tarballs. vim-7.1.tar.bz2, vim-7.1-extra.tar.gz, and
>> vim-7.1-lang.tar.gz. The extra tarballs are under the extra directory
>> on the ftp server.
>>
>
> Which is a 'no', in case that wasn't clear. To get everything, you need to get the
> three tarballs, which are designed to be extracted 'on top of' each other, i.e.
> their contents get merged together to obtain the whole set of sources.
>
> Ben.
>
Ok, never mind. We'll just skip the updates for now then... Having
multiple tars to unpack just doesn't work well with our build system.
Different question: can the targets be broken up in the Makefile so
that you have finer granularity of what gets installed?
We're trying to "skinny up" the package, and don't want the docs/man
pages installed...
-Philip
Gary Johnson
> Ben Schmidt wrote:
> >>> So... is there a tarball that contains everything then?
> >>>
> >> There are 3 tarballs. vim-7.1.tar.bz2, vim-7.1-extra.tar.gz, and
> >> vim-7.1-lang.tar.gz. The extra tarballs are under the extra
> >> directory on the ftp server.
> >>
> >
> > Which is a 'no', in case that wasn't clear. To get everything,
> > you need to get the three tarballs, which are designed to be
> > extracted 'on top of' each other, i.e. their contents get
> > merged together to obtain the whole set of sources.
> Ok, never mind. We'll just skip the updates for now then... Having
> multiple tars to unpack just doesn't work well with our build system.
You only have to fetch and unpack them once per major release, so it
shouldn't be a big deal. Everything is configured and built from
the top-level configure and make commands.
> Different question: can the targets be broken up in the Makefile so
> that you have finer granularity of what gets installed?
>
> We're trying to "skinny up" the package, and don't want the docs/man
> pages installed...
The various install targets are documented in the comments at the
top of vim71/src/Makefile, item #5.
Regards,
Gary
Philip Prindeville
> On 2008-01-07, Philip Prindeville <philip...@redfish-solutions.com> wrote:
>
>> Ben Schmidt wrote:
>>
>>>>> So... is there a tarball that contains everything then?
>>>>>
>>>>>
>>>> There are 3 tarballs. vim-7.1.tar.bz2, vim-7.1-extra.tar.gz, and
>>>> vim-7.1-lang.tar.gz. The extra tarballs are under the extra
>>>> directory on the ftp server.
>>>>
>>>>
>>> Which is a 'no', in case that wasn't clear. To get everything,
>>> you need to get the three tarballs, which are designed to be
>>> extracted 'on top of' each other, i.e. their contents get
>>> merged together to obtain the whole set of sources.
>>>
>
>
>> Ok, never mind. We'll just skip the updates for now then... Having
>> multiple tars to unpack just doesn't work well with our build system.
>>
>
> You only have to fetch and unpack them once per major release, so it
> shouldn't be a big deal. Everything is configured and built from
> the top-level configure and make commands.
>
Except that, as I explained, the infrastructure doesn't expect to have
more than one tarball to unpack.
(Which given that amongst the 200+ other packages this is true... the
only exception being the "add ons" to Asterisk... this has been a
reasonable assumption.)
>> Different question: can the targets be broken up in the Makefile so
>> that you have finer granularity of what gets installed?
>>
>> We're trying to "skinny up" the package, and don't want the docs/man
>> pages installed...
>>
>
> The various install targets are documented in the comments at the
> top of vim71/src/Makefile, item #5.
>
> Regards,
> Gary
>
Yeah... about that comment. It's misleading.
"installruntime" also installs "installrtbase", which includes vim.1 and:
-$(SHELL) ./installman.sh install $(DEST_MAN) "" $(INSTALLMANARGS)
@echo generating help tags
# Generate the help tags with ":helptags" to handle all languages.
-@cd $(HELPSOURCE); $(MAKE) VIMEXE=$(DEST_BIN)/$(VIMTARGET) vimtags
cd $(HELPSOURCE); \
files=`ls *.txt tags`; \
files="$$files `ls *.??x tags-?? 2>/dev/null || true`"; \
$(INSTALL_DATA) $$files $(DEST_HELP); \
cd $(DEST_HELP); \
chmod $(HELPMOD) $$files
$(INSTALL_DATA) $(HELPSOURCE)/*.pl $(DEST_HELP)
chmod $(SCRIPTMOD) $(DEST_HELP)/*.pl
since when do man pages and help files come under the rubric of "runtime"?
-Philip
Philip Prindeville
> On 2008-01-07, Philip Prindeville <philip...@redfish-solutions.com> wrote:
>
>> Ben Schmidt wrote:
>>
>>>>> So... is there a tarball that contains everything then?
>>>>>
>>>>>
>>>> There are 3 tarballs. vim-7.1.tar.bz2, vim-7.1-extra.tar.gz, and
>>>> vim-7.1-lang.tar.gz. The extra tarballs are under the extra
>>>> directory on the ftp server.
>>>>
>>>>
>>> Which is a 'no', in case that wasn't clear. To get everything,
>>> you need to get the three tarballs, which are designed to be
>>> extracted 'on top of' each other, i.e. their contents get
>>> merged together to obtain the whole set of sources.
>>>
>
>
>> Ok, never mind. We'll just skip the updates for now then... Having
>> multiple tars to unpack just doesn't work well with our build system.
>>
>
> You only have to fetch and unpack them once per major release, so it
> shouldn't be a big deal. Everything is configured and built from
> the top-level configure and make commands.
>
Well, it gets worse: Unix vim is bzip2'd, whereas the language and
extras stuff is gzipped.
Which makes the script to pull down and build the stuff even more
useless, since packages can only specify one uncompression method, etc...
-Philip
Philip Prindeville
The process that we use is simple and lightweight, and in that it serves
our needs.
It only falls on its face when we're presented with scenarios that are
significantly more complicated than they have to be.
For instance, what's the compelling reason for not having the source be
in a single tarball? Or for that matter, not packaging all tarballs
with the same compression? (I think KISS went out the window at some
point here...)
-Philip
Tony Mechelynck
[...]
> Well, it gets worse: Unix vim is bzip2'd, whereas the language and
> extras stuff is gzipped.
>
> Which makes the script to pull down and build the stuff even more
> useless, since packages can only specify one uncompression method, etc...
>
> -Philip
Sounds that your autoinstall software is too rigid.
Maybe you can make it work by defining three packages (vim-base, vim-extra and
vim-lang, maybe), with vim-base being a requirement for each of the other two.
Oh, and maybe a fourth: vim-runtime, which requires or is required by
vim-base, I'm not sure which, has no specific files to install (install a
dummy file if you can't work around that) and is distinguished by its distinct
upgrade method (using rsync followed by -for instance- gmake -C src
installruntime)
Best regards,
Tony.
--
If you want to understand your government, don't begin by reading the
Constitution. It conveys precious little of the flavor of today's
statecraft. Instead, read selected portions of the Washington
telephone directory containing listings for all the organizations with
titles beginning with the word "National".
-- George Will