[Daniel Shahaf]
> The current patch's docstring implies the LF byte is necessarily part
> of a line terminator, which is true for UTF-8/16/32 but not
> necessarily true in arbitrary encodings.
Nitpick: It is true in UTF-8, but not -16 or -32. There are about 70
characters in the BMP which, in U
[Martin Furter]
> Attached is a log message and a patch which adds the new options
> '--password-file' and '--password-envvar'.
I don't agree with --password-envvar. If we're going to support
reading a password from the environment at all, just do what everyone
always does with the environment:
[Julian Foad]
> Do we really want a new subcommand "svn youngest" for this?
>
> We already have:
>
> svnversion
> # youngest rev in a WC
>
> svn info $URL | grep 'Revision:'
> # head revision of repo in which $URL exists
As Johan has already noted, it's slightly more complicated.
[Peter Samuelson]
> Note also, if you _are_ worried about command line length limits, it's
> easy to buy yourself a lot more breathing room:
>
> cd subversion/tests/cmdline/svn-test-work; rm -fr *
Of course I meant && in place of ; there. Much safer in case the
[Ben Reser]
> I started this usage with r1421636. The purpose is to avoid length
> limitations
> on the argument list not spaces creating problems. We could change it to
> just:
> rm -rf subversion/tests/cmdline/svn-test-work/*
Note also, if you _are_ worried about command line length limits,
[Stefan Fuhrmann]
> Fixed in r1567985 using Peter's suggestion.
James, not me! He's been awesome on the Debian Subversion bits these
past few months, doing a lot more of the work than I.
[Dirk]
> It doesn't make a lot of sense. These special files are platform
> depending and there is no point in having them in /any/ repository.
> Even if it is a project that is only for a single platform it doesn't
> make sense storing special files in the repository. Symlinks, device
> files, et
> > +1, except I'd condense --diff-all and --show-all-paths to a single
> > additional option named, I dunno, --full-revision.
[Julian Foad]
> My latest thought in that area is like I listed above except omitting
> the --diff-all option entirely -- after all, nobody has requested it
> and it doe
[Julian Foad]
> svn log TARGET [SUBTREE...]
> --diff// diff of TARGET [SUBTREE...]
> --diff-all// diff of whole commit
> --show-paths // changed-paths for TARGET [SUBTREE...]
> --show-all-paths // changed-paths for whole commit; alias -v
> -v/--verbo
> > Well, I forgot about "svn log --diff -l1 new_foo".
[Tobias Bading]
> Good idea, but unfortunately no cigar.
You're right. I tested that command but somehow glazed over the fact
that it did not do what I said it did. Sorry. Anyway, parsing the
'svn log -v -l1 {filename}' output, then runni
[Tobias Bading]
> No disrespect & thank you for the hint, but shouldn't a version
> control system be able to answer the question "what's changed?"
> without making you jump through hoops?
Well, I forgot about "svn log --diff -l1 new_foo".
[Tobias Bading]
> Seriously though, what would you have to do if you have the path of a
> FILE in the working copy and a revision number N and you would like
> to know what was changed in that file in that revision?
Something like this:
$ LC_ALL=C svn log -v -l1 new_foo
-
> If you really want to push, then "proxy-hates-chunks" could work well.
Oh man. Not "proxy-blows-chunks"? (SCNR.)
[Ben Reser]
> Actually now that I think about it a bit more I'm not sure that
> helps. It'll probably just shift it to a link time error because the
> defines will be there so it'll build, SWIG will generate wrappers for
> them that depend on the functions in our libraries, which won't be
> avail
[Greg Stein]
> But I'll go one step further: you shouldn't care at all.
>
> I could release 1.2.2 tomorrow with all kinds of crap. Or maybe the
> day after 1.8.0 goes final. Not much you can do about it. Subversion
> needs to soak its own code, not the entire dependency stack.
You could, but 1.2
[Ben Reser]
> I've added the needed .ycm_extra_conf.py and a make target to produce
> the compilation database in r1476374. So using these plugins with the
> Subversion code base should be as simple as installing the plugins
> into vim per their directions, installing bear, running make clean &&
Yay, a bikeshed discussion!
[Daniel Shahaf]
> % $svn upgrade /
> subversion/svn/upgrade-cmd.c:73: (apr_err=_)
> subversion/libsvn_client/upgrade.c:112: (apr_err=_)
> subversion/libsvn_wc/upgrade.c:2194: (apr_err=_)
> subversion/libsvn_wc/wc_db.c:15006: (apr_err=SVN_ERR_WC_INVA
> Julian Foad wrote on Fri, Mar 22, 2013 at 15:48:56 +:
> > If I'm runnning a 1.7 svnadmin and I request "--compatible-version=1.9.0",
> > then certainly 1.7 *can* create a repository that's compatible with v1.9,
> > but I think the meaning should be: create a repo using the 1.9 format, that
[Philip Martin]
> On my Debian box apxs does the right thing:
Wow, I wonder when that changed. I definitely had to work around this
issue many years ago - but after that, I never checked back to see if
apxs would magically detect the need to run libtool to install
something. You're right, now i
> > That reminds me. We really should be installing Apache modules with
> > 'libtool --mode=install', because on some platforms that is _not_ just
> > a simple copy like you'd expect; sometimes it has to do other things.
[Philip Martin]
> We currently use Apache's apxs to install mod_dav_svn and
[Andreas Stieger]
> The installation of mod_dontdothat was moved to make install-tools,
> however the trunk code tries to install with libtool which fails with
> the message: cannot install mod_dontdothat.la to a directory not ending
> in [...]/lib/apache2/modules
That reminds me. We really shou
[Justin Erenkrantz]
> Because GNU libtool always compiles code twice on Mac OS X (insert rant
> against GNU libtool here)
...
> But, then again, I always like reminding devs how evil libtool is and
> that it's double-compiling everything. =P
Well, you asked it to build both static and shared lib
> On Mon, Dec 17, 2012 at 01:44:43PM -0600, Peter Samuelson wrote:
> > [Stefan Sperling]
> > > We could use iatty() to enable --non-interactive if output is not
> > > going to a terminal, for instance.
> >
> > I floated this idea some time ago and I
[Stefan Sperling]
> We could use iatty() to enable --non-interactive if output is not
> going to a terminal, for instance.
I floated this idea some time ago and I'm still in favor of it. But I
think a simple isatty(STDERR_FILENO) would be wrong. What you want is
to detect that there is a contro
> * Search for clang as well as the default gcc/cc, and prefer clang(++)
> over gcc/g++.
Is clang considered superior, then? Fair enough, I haven't really kept
up.
> * Add -pipe to C(XX)FLAGS if the compiler supports it. This speeds up
> compilation a bit in my tests.
Hmm. It seem
> http://anonscm.debian.org/viewvc/pkg-subversion/src/1.7.x/debian/patches/
(Or svn://anonscm.debian.org/pkg-subversion/src/1.7.x/debian/patches .)
> > +LENGTH =
> > svn.core.svn_checksum_size(svn.core.svn_checksum_create(svn.core.svn_checksum_md5))
> > +self.assertEqual(len(check_val)%LENGTH,0,"Length of digest does
> > not match kind")
Is there a better way to get the expected length?
svn.core.svn_checksum_create(svn.core.svn_ch
[Philip Martin]
> I assume WANdisco's package is intended to replace the libraries in the
> standard Debian or Ubuntu libsvn1 package, in which case you need to use
> the same patch. If you ship -1.so.0 libraries then applications linked
> to the -1.so.1 libraries will fail to start.
Well, they'
> > "### http-library Which library to use for
> > http/https"
> >
> > NL
> > "### connections."
> > NL
> > +"### bulk_upda
> Eric S. Raymond wrote on Tue, Dec 04, 2012 at 19:54:17 -0500:
> > O(1) cost vs. O(n) cost, where n is the number of repos. Q.E.D.
[Daniel Shahaf]
> No, O(n) cost <=> O(m) cost, where M is Ω(the number of homedirs).
And also, the O(n) is piggybacked on top of another cost that is
_already_ O(n
(Sorry, still feeling a bit verbose.)
[Eric S. Raymond]
> 1. They have enough entropy that collisions aren't a practical problem.
> A human name alone does not. I'm excluding deliberate spoofing from
> the analysis because we now have enough experience with un-cryptosigned
> commits in DVCSes to
[Eric S. Raymond]
> 1. Add support to the client tools for shipping a FULLNAME field
> mined from somewhere under ~/.subversion. Maybe the existing
> username entry will do, maybe it won't - I see arguments both ways.
> I don't care, we can fill in that detail later.
This part (upon which your
[stef...@apache.org]
> * subversion/libsvn_fs_fs/util.h
> (RECOVERABLE_RETRY_COUNT,
[...]
>move_into_place): lib-locally declare functions previously
>private in fs_fs.c
This is a problem - on many OSes[*], all global functions and variables
that are not 'static', i.e., anything not
[Peter Samuelson]
> If the "misspelled" property exists, probably the user already noticed
> the typo, that's why they're deleting it! I see no need for --force
> here.
>
> If the "misspelled" property does not exist, I think the warning that
>
[Julian Foad]
> In general, setting *or* deleting an unknown prop name causes nothing
> significant to happen on *this* client, and may cause something
> (expected or unexpected) to happen on another client.
I don't get why we would want 'propdel --force' at all. Either the
"misspelled" property
[Philip Martin]
> If I configure a server with an FSFS cache that uses about 50% of
> available memory and then I use the server so the cache is in use I
> find that hook scripts fail to run because the fork/exec cannot
> allocate memory.
You didn't say what OS this is. It matters. Some are con
[Daniel Shahaf]
> Did you mean:
> $ printf 'link bar' > foo
Yes I did mean that - thanks.
> > $ svn add --config-option config:miscellany:enable-auto-props=yes \
> > --config-option config:auto-props:foo=svn:special=1 foo
> > A foo
> >
> > $ ls -l foo
> >
[Daniel Shahaf]
> it's what allows Windows users to create versioned symlinks:
>
> printf "link bar" > foo && svn add foo && svn ps svn:special yes foo && svn
> ci
>
> If we don't like changing the specialness of a local addition, we could
> deprecate (or break) that behaviour and have people
[Michael Chletsos]
> sorry about confusion - here is the updated patch, with swig updates.
Your patch seems to be reversed ('diff -u {new} {old}' whereas what
everyone wants to see is 'diff -u {old} {new}' or 'svn diff'), and also
seems to have been developed against something older than Subversi
[Branko Čibej]
> "ignored" has /never/ meant that you couldn't "svn add" a file that
> matches the ignore pattern. Therefore, --no-ignores should always
> ignore all ignores.
And for people who want the other behavior, maybe we could add a
--no-ignores-well-ok-fine-maybe-some-ignores-but-not-all-
[Branko Čibej]
> On 26.10.2012 21:04, C. Michael Pilato wrote:
> > Just felt like painting.
>
> The only problem I see with this is that, in many monospaced fonts, '
> and ` glyphs are not mirror images; whereas / and \ almost always are.
Well, note that his patch uses the symmetry of ` and , wh
Arfrever, Jaroslaw, Karol: you have been involved in po: pl translation
for Subversion. Can you look at Jakub's report here and fix whatever
needs to be fixed? (This is a fwd from http://bugs.debian.org/690815 .)
Thanks,
Peter
[Jakub Wilk]
> po/pl.po has this message:
>
> msgstr "--- Łączenie
[Ben Reser]
> Just confirming what brane said above is the reason why I did not try
> to just build detection of BDB into our configure system. Figuring
> out if it's safe to link to some BDB that we find ourselves is
> actually really hard. If we could ask APR-Util what version of BDB it
> was
[bre...@apache.org]
> + # We pass --dbm-libs here since Debian has modified apu-config not
> + # to return -ldb unless --dbm-libs is passed.
Better would be not to rely on apr-util to figure out where db is at
all. We're not using the apu wrapper for db, after all, we're calling
the db
>for (; len > 0; ++data, --len)
> - if (*data < 0)
> -return data;
> +if (*data < 0 || *data >= 0x80)
> + return data;
A reasonable compiler will collapse it anyway, but this is shorter and
more direct:
if (*data & 0x80)
Peter
[stef...@apache.org]
> + for (; len > 0; ++data, --len)
> + if (*data < 0)
> +return data;
Two major problems:
1) It doesn't account for character sets like Shift-JIS, where state
change is signalled by ASCII 14 and 15 ("shift out", "shift in")
2) It assumes a 'char
[Philip Martin]
> There needs to be a way to create the initial branch, i.e. mkdir as well
> as copy.
In fact, that's really _all_ that should be needed. If your 'trunk'
has a svn:branch property, and you copy or tag it with 'svn copy', the
target will get the same property. An explicit 'svn co
[Branko Cibej]
> Like I said in my response to this in the other thread -- API or even
> ABI compatibility is not the issue. Working copy formats, wire
> protocol quirks, etc. etc. are more "interesting". And I really don't
> think it's up to us to tell packagers how to do their stuff.
Well, the
Reposting under a new thread + subject line, at Daniel's suggestion.
[Markus Schaber]
> So my personal experience tells me that multiple-client scenarios are
> the common case, and that the deployment strategy (only using linux
> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
[Markus Schaber]
> So my personal experience tells me that multiple-client scenarios are
> the common case, and that the deployment strategy (only using linux
> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> problem.
So, we provide a pile of libraries that maintain ABI backw
[Mattias Engdegård]
> The biggest surprise was that COW actually made the checkout slightly
> slower, even though no "true" file copies were made. I'm not sure how
> to explain this---perhaps everything is already in cache so the
> copies aren't very expensive, or the COW operations are somehow
>
[Greg Stein]
> That looks fine. There are likely a couple other ways to do it more
> generically (my Pay API Fu is rusty), but that code should be okay. We can
> investigate more if we run into further problems.
Thanks, r1351117.
For reasons I do not understand, swig 2.0.5 and higher has changed
handling of python ints and longs in some way that breaks the Python
testsuite. This fixes it. The testsuite. I don't know if it fixes
the real issue, I have no idea if it's a reasonable approach. I'm not
at all comfortable wit
[Markus Schaber]
> A simple "check for update" could be done sending a single UDP packet
> containg a list of keys (package names, uuids or similar), and the
> reply is another UDP packet containing the available versions.
This sort of thing is, in fact, often done in DNS. (A "single UDP
packet"
[stef...@apache.org]
> Minor svn: latency improvement: call dcgettext for error messages
> only if an error actually occurred.
>
> * subversion/libsvn_ra_svn/client.c
> (handle_unsupported_cmd): translate message here ...
> (ra_svn_stat, ra_svn_get_locations, ra_svn_get_location_segments,
>
[Greg Stein]
> > - int argc = 1;
> > - app = new QCoreApplication(argc, (char *[1]) {(char *) "svn"});
> > + int argc = q_argc;
> > + app = new QCoreApplication(argc, q_argv);
>
> Why keep argc around? Just use q_argc.
Because argc is passed by reference (int &argc) and I fig
[Bert Huijben]
> Then there is a different problem that you found: We have triggers
> that detect invalid database states when SVN_DEBUG is defined in
> wc_db_wcroot.c. These are currently depend on parent nodes being
> changed before their children, which is not guaranteed by the SQL
> specifica
[Greg Stein]
> A following question asks about API compatibility. I believe we can
> simply sub ra_serf into any loader/query for ra_neon. Hard linkage to
> the ra_neon library may also need a solution (it becomes a shim?).
I was concerned with this exact issue when libsvn_ra_dav was renamed to
l
.c.
Current svn: foo.c mtime is set to the present time. It is now newer
than foo.o. [Of course you can set foo.o's mtime in the future, but
that's just breaking things _on purpose_.]
Your proposal: foo.c may or may not get a newer timestamp than it had.
If not, you lose. If so, this t
[Hyrum K Wright]
> I think we can reasonably assume that Python 2.5 is generally
> available. For reference, we currently require and SQLite that is
> only 2.5-years-old.
Obligatory "what about Debian users, since that platform is always so
far behind": the oldest supported Debian release, lenny
y, someone at Github fixed their server-side bug as a
result of your report.
So, thanks!
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[Philip Martin]
> --- ../src/subversion/libsvn_subr/svn_base64.c (revision 1242045)
> +++ ../src/subversion/libsvn_subr/svn_base64.c (working copy)
> @@ -410,7 +410,7 @@
>/* Resize the stringbuf to make room for the (approximate) size of
> output, to avoid repeated resizes later.
>
> On 02.02.2012 20:22, Peter Samuelson wrote:
> > By proposing a client-only solution, I hope to avoid _all_ those
> > questions.
[Branko Cibej]
> Can't see how that works, unless you either make the client-side
> solution optional, create a mapping table, or make n
[Hiroaki Nakamura]
> Existing repositories, I think it would be better to convert them too using
> svndump/svnload. And we change svnload to convert filenames to NFC.
> However in reality we cannot force users to convert every existing repository.
Also note that if you convert a repository (via d
ouble. Or we could
just say "use a pre-commit hook," like we tell people who want to
prevent REAMDE and Reamde in a single dir. It is not the same level of
interoperability problem as the one this thread is about.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[reordering the conversation flow slightly]
[Peter Samuelson]
> > That's the implementation I would like to see, to be honest. Start
> > with the observation that we can treat Mac OS X NFD paths as a
> > client character encoding. Now observe that it is lossy. But
[Stefan Sperling]
> It is indeed harder because we are passing paths verbatim to sqlite.
> I doubt having more than one form of a given path in wc.db is fun...
That's the implementation I would like to see, to be honest. Start
with the observation that we can treat Mac OS X NFD paths as a client
[Stefan Sperling]
> > We could also open the parent directory, read all the filenames
> > within it, normalise them all, and then search the resulting
> > list. This works, expect if a name exists twice, once in NFC form
> > and once in NFD form. We'd somehow have to solve the name collision
> >
[Branko Cibej]
> It'd certainly be better to somehow get regular expressions included
> in APR.
The only problem there (aside from the apr 1.0 feature freeze you
mentioned) is that there are so many flavors of RE out there (Emacs,
Perl/PCRE/C#, POSIX Basic, POSIX Extended, and one or two others)
[Joe Schaefer]
> They're using the ASF CMS to manage the www.openoffice.org website,
> which is full of 10 years worth of accumulated legacy spanning 50 or
> so different natural languages. The CMS is "too slow" during commits
> to template files or such which change the generated html content of
[Eric S. Raymond]
> 1. In the Credits section I note that portions of this document are
> derived from notes by Ben Sussman
*Ben Collins-Sussman
[Stefan Sperling]
> On Thu, Dec 15, 2011 at 04:04:13PM -0600, Peter Samuelson wrote:
> > http://packages.debian.org/sid/eatmydata
> > https://launchpad.net/libeatmydata
> >
> > It apparently works on Linux and Solaris. Don't know if that's eno
[Philip Martin]
> If we had such a flag in fsfs.conf (Stefan suggests
> "eat-my-data=yes") the code could write all the same data in the same
> order but avoid making any flush calls thus allowing the OS to order
> physical writes for optimum speed.
Given the main use case is a distinct svnadmin
> Peter Samuelson wrote on Wed, Dec 14, 2011 at 18:16:27 -0600:
> > What you want is to pipe these emails into 'wdiff -ct | less -r'. With
[Daniel Shahaf]
> Thanks for the tip!
>
> What version of wdiff do you have? On my system I have 0.6.3-1, which
> seems to
[Daniel Shahaf]
> > Is there any way to get line-based (rather than paragraph-based) diffs
> > from the wiki? That would enable reviewing them.
[C. Michael Pilato]
> You are seeing line-based diffs. It's just that that lines are
> unmanagably long. :-)
What you want is to pipe these emails i
item under the current directory".
If this rather dramatic speed difference between 'status' and 'commit'
is really a common case, it's probably worth reimplementing 'commit' in
terms of the same thing 'status' does. But I'm not deep enough in
-party modules
would need to do the same thing I'm patching mod_authz_svn to do.) If
so, we can leave the original prototype in the public mod_dav_svn.h
instead of moving it, as I've done below.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[[[
Use apr_optional.h f
[Hyrum K Wright]
> "The username on my local box is different than my username on the server,
> and I don't want to cache passwords. How can I cache just the username?"
Aside from the real answer Stefan gave, with svn+ssh you can specify
user@server in the URI, and that is retained. Alternative
rms with
Apache 2.0. I don't _think_ we've ever dropped support for our
original apr platform, have we?)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
r than apr_time_now().
> No objection here, but doesn't APR already use lrand48() if it's available?
If that's true, we shouldn't even be having this conversation at all.
The problem is that /dev/random was being exhausted.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
nches dir. But either way
makes more sense than pretending trunk is not a branch.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
but then when I scrolled down the file a bit, I
found this:
#if _MSC_VER >= 1400
/* ### This should work for VC++ 2002 (=1300) and later */
So, what should it be? 1300 or 1400?
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[Steven Wu]
> I am looking to revamp the entire site. Not just a minor update. But I like
> to redevelop it with modern technology using HTML5, CSS3 and bit of JQuery.
> There would be major overhaul, from styling, structure, making it
> more engaging, possibly changing the navigation so it has d
n inoperative.)
Such non-inheritable MI can be converted to inheritable, which of
course makes other elision cases possible.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
cleanup that could be
applied separately. I could go either way. It is a micro-optimization
on a set of changes whose original purpose was optimization.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[Stefan Sperling]
> However, the merge meisters I've met are usually more competent in
> using svn than the average developer in the same organisation. Often
> they're even the local svn gurus. I would trust them to give special
> consideration for files with svn:hold. If the merge meister canno
t, in r1158343. strcat seemed appropriate
anyway, even without the confusing nesting issue. Hope nobody minds.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
. it should be on
> users@s.a.o
Because he's asking for (discussion about) a proposed new feature for
'svn update'.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[Peter Samuelson]
> (It's news to me, in fact, that it was even possible to build a
> recent version of neon in such a way that it doesn't support the
> features we use.)
Followup from IRC: we determined that the reason Doug's neon library
didn't support XML fun
> On Wed, Aug 3, 2011 at 3:03 PM, Peter Samuelson wrote:
> > Further checking: the new exception syntax is new to Python 2.6.
> > Given that this script is only used in dev builds (not from
> > tarballs), someone remind me: what's our Py version requirement for
#x27;t
really make sense to use it for building source either.
Further checking: the new exception syntax is new to Python 2.6.
Given that this script is only used in dev builds (not from tarballs),
someone remind me: what's our Py version requirement for dev builds?
It is not specified in IN
at will work for us" is pretty small.
(It's news to me, in fact, that it was even possible to build a recent
version of neon in such a way that it doesn't support the features we
use.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
e. And then, Tom is correct: the delta of the encrypted stream
will extend from the first change all the way to the end of the file,
and any storage mechanism (including a Subversion server) that does not
have access to plaintext will not be very efficient.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
eterministic. But typically,
I reintegrate my own branches, so I prefer to skip the extra step and
the extra rev.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
y just a special case of
content moving between files.
Note that the complexity of this approach (deducing content moves after
the fact, rather than tracking tree changes) scales by the size of the
commit, not the size of the tree. So the assumption is that even in
large trees, any given commit is re
lhost' does not map to an IPv6 address (should
be ::1). But, given the 3 distinct errors I've seen, it's not clear to
me that it's just one bug, there may be 2 or 3 related bugs here.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[Greg Stein]
> We have already worked around the bug in 3.7.7. There is no need to
> disable support for that version.
I think what he means is, remove our workaround for 3.7.7. There
should be almost no installations, and if there are any, they will
get an immediate error message upon svn invoc
> Peter Samuelson writes:
> > My patch is pretty crude, to Makefile.in:
> >
> > $(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL
> > - cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
> > + cd $(SWIG_PL_DIR)/native; \
> > +
ld
be found, working _with_ ExtUtils::MakeMaker instead of against it.
Besides being crude, it uses sed -i, which works on my platform but is
not portable. (Portable is to redirect sed to a temp file and then
rename it to the original, which here would involve a shell loop.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
svn fetch'ing from an
> svn+ssh:// repository.
Thanks, yes, that works. Just voted for the patch, so it will probably
go into 1.7.0.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
1 - 100 of 240 matches
Mail list logo
