[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] openpty patch again

From: Humberto Ortiz-Zuazaga
Subject: Re: [Axiom-developer] openpty patch again
Date: Thu, 30 Nov 2006 22:05:24 -0400
User-agent: Thunderbird (Macintosh/20061025)

Gabriel Dos Reis wrote:

> | The procedure to build this version of axiom is not too bad. Fink still
> | seems to cause problems if the build machinery can see it, so I delete
> | it from the path.
> we can configure-detect that and set PATH accordingly.
> | One caveat is that you need latex, makeindex, and
> we can ask configure to return the absolute path so that there would
> be no need to symlink from somewhere else.

Can you reccomend a reference on configure tricks like that? I've looked
at the info pages, but can't figure out how to do that.

> | but svk patch complains:
> |   
> | $ svk patch --view pty-again
> | Target not local nor mirrored, unable to view patch.
> From the top my head, I don't see what that means.  I'll have to go back.

The help for svk patch says:

    Suppose you mirror project foo to //mirror/foo, create a local copy on
    //local/foo, and check out to ~/dev/foo. After you've done some work,
    you type:

        svk commit -m "Add my new feature"

    to commit changes from ~/dev/foo to //local/foo. If you have commit
    access to the upstream repository, you can submit your changes directly
    like this:

        svk push //local/foo

    Sometimes, it's useful to send a patch, rather than submit changes
    directly, either because you don't have permission to commit to the
    upstream repository or because you don't think your changes are ready
    to be committed.

    To create a patch containing the differences between //local/foo and
    //mirror/foo, use this command:

        svk push -P Foo //local/foo

But I don't have and don't know how to make the "local copy //local/foo"
corresponding to my upstream repository stored in //mirror/axiom

> It would be good if you could integrate the suggestions here:
> In particular, we want to distinguish between the symbol openpty
> (HAVE_OPENPTY) and its declaration (HAVE_OPENPTY_DECL).

I forgot about that email. I'll try to incorporate your suggestions.

> There is no standard C preprocessor directive #elifdef.  I believe you
> wanted to say
>     #elif defined(HAVE_UTIL_H)

I stole the snippet from a python mailing list, I guess they use gcc too

Humberto Ortiz-Zuazaga
University of Puerto Rico

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]