Larson, Timothy E. | 1 Jul 15:48 2008

using -f for make

The main makefile for a new package I'm working with does not use a standard
name, so the pkgsrc build process can't find it when it descends to the work
directory.  How do I tell the package Makefile where the source's makefile
is?

Thanks,
Tim

--

-- 
Tim Larson        AMT2 Unix Systems Administrator
    InterCall, a division of West Corporation

               Eschew obfuscation!
Attachment (smime.p7s): application/x-pkcs7-signature, 12 KiB
reilles | 1 Jul 16:06 2008
Picon

Re: using -f for make

Hi,

Quoting "Larson, Timothy E." <TELarson <at> west.com>:
> The main makefile for a new package I'm working with does not use a standard
> name, so the pkgsrc build process can't find it when it descends to the work
> directory.  How do I tell the package Makefile where the source's makefile
> is?
You should look at
http://www.netbsd.org/docs/pkgsrc/build.html
where the WRKSRC variable is described.
You should set it in the package Makefile to where the distfile is extracted.

Cheers,
antoine

Jeremy C. Reed | 1 Jul 16:14 2008
Picon

Re: using -f for make

> The main makefile for a new package I'm working with does not use a standard
> name, so the pkgsrc build process can't find it when it descends to the work
> directory.  How do I tell the package Makefile where the source's makefile
> is?

Use MAKE_FILE. Many examples in pkgsrc.

See pkgsrc Guide (pkgsrc/doc/pkgsrc.txt):

The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains 
"gmake", "make" otherwise. The default value of MAKE_FILE is "Makefile", 
and BUILD_TARGET defaults to "all".

Adam Hoka | 1 Jul 16:15 2008
Picon

Re: using -f for make

Larson, Timothy E. wrote:

> The main makefile for a new package I'm working with does not use a standard
> name, so the pkgsrc build process can't find it when it descends to the work
> directory.  How do I tell the package Makefile where the source's makefile
> is?
> 
> Thanks,
> Tim
> 

Like this:

MAKE_FILE=       GNUmakefile

HTH,

--
Adam
Larson, Timothy E. | 1 Jul 16:23 2008

RE: using -f for make

Jeremy C. Reed <mailto:reed <at> reedmedia.net> wrote:
> Use MAKE_FILE. Many examples in pkgsrc.
> 
> See pkgsrc Guide (pkgsrc/doc/pkgsrc.txt):
> 
> The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains
> "gmake", "make" otherwise. The default value of MAKE_FILE is
> "Makefile", and BUILD_TARGET defaults to "all".  

That sounds like what I needed - thanks!

It would be _really_ helpful if the Guide had an appendix of all the
makefile variables and what they did.  I read through all the sections that
seemed like they'd be relevant to this question, but didn't find this
answer.

Tim

--

-- 
Tim Larson        AMT2 Unix Systems Administrator
    InterCall, a division of West Corporation

               Eschew obfuscation!
Attachment (smime.p7s): application/x-pkcs7-signature, 12 KiB
Aleksej Saushev | 1 Jul 19:33 2008
Picon

Re: using -f for make

"Larson, Timothy E." <TELarson <at> west.com> writes:

> It would be _really_ helpful if the Guide had an appendix of all the
> makefile variables and what they did.  I read through all the sections that
> seemed like they'd be relevant to this question, but didn't find this
> answer.

I doubt, that it is good addition to the Guide, it just
overloads it with mostly useless information, in my opinion,
but it sounds like a wrapper around "make help".

--

-- 
CE3OH...

NetBSD source update | 2 Jul 08:11 2008
Picon

daily pkgsrc CVS update output


Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/audio/sweep/Makefile
P pkgsrc/audio/sweep/PLIST
P pkgsrc/audio/sweep/distinfo
P pkgsrc/audio/sweep/patches/patch-ab
P pkgsrc/chat/smirk/Makefile
P pkgsrc/chat/smirk/PLIST
P pkgsrc/chat/smirk/distinfo
U pkgsrc/chat/smirk/patches/patch-aa
P pkgsrc/databases/mysql5-client/Makefile
P pkgsrc/databases/mysql5-client/Makefile.common
P pkgsrc/databases/mysql5-client/buildlink3.mk
P pkgsrc/databases/mysql5-client/distinfo
P pkgsrc/databases/mysql5-server/Makefile
P pkgsrc/databases/mysql5-server/distinfo
P pkgsrc/databases/mysql5-server/patches/patch-ad
U pkgsrc/databases/mysql5-server/patches/patch-da
U pkgsrc/databases/mysql5-server/patches/patch-db
P pkgsrc/databases/rrdtool/Makefile
P pkgsrc/databases/rrdtool/distinfo
P pkgsrc/databases/rrdtool/patches/patch-al
P pkgsrc/databases/rrdtool/patches/patch-am
P pkgsrc/devel/subversion/DESCR
P pkgsrc/devel/subversion/Makefile
P pkgsrc/devel/svk/Makefile
P pkgsrc/doc/CHANGES-2008
(Continue reading)

Aleksey Cheusov | 2 Jul 13:50 2008
 >> On Mon, Jun 23, 2008 at 12:15:28PM +0200, Alan Barrett wrote:
 >>  > On Mon, 23 Jun 2008, David Holland wrote:
 >>  > > I suppose the Dewey logic is upset that 0.5 > 0.40? Unfortunately,
 >>  > > many packages are versioned that way.
 >>  > 
 >>  > Perhaps the 0.5 should have been 0.50?  I don't know anything about
 >>  > this particular package, but I do think that it a very bad thing for a
 >>  > version number to go backwards.
 >>
 >> Yeah, presumably. Unfortunately (as the longer list of downgrades that
 >> was posted elsewhere shows) this interpretation of minor version
 >> digits is fairly common. While having the version number go backwards
 >> is bad, rearranging the version number semantics so as to disagree
 >> with upstream is probably bad too...

> upstream realized the problem and released 0.60, which I put in pkgsrc
> yesterday.

This is good, but the real problem is not with this particular package
but with that there is no control for downgrades at all.
Today I've filled a PR about this problem.

--

-- 
Best regards, Aleksey Cheusov.

David Holland | 3 Jul 02:59 2008
Picon

Re: 2008Q1 -> current: downgrade

On Thu, May 22, 2008 at 11:51:12AM +0300, Aleksey Cheusov wrote:
 > [downgrades]
 >
 > pkgsrc versions fetched by 'cvs up -D<DATE>'

The overwhelming majority of what you've found are actually upgrades
documented perfectly well in CHANGES-*. They show up as downgrades to
you and/or pkgsrc-dewey because of disagreements about the semantics
of version numbering, most commonly:

 o  Dated snapshots normally come before numbered releases, but you're
describing the transition as a "downgrade".

 o  Disagreement over whether 1.19 > 1.2 (the "dewey" approach) or 
1.2 > 1.19 (the "decimal number" approach).

 o  Disagreement over whether an alpha/beta version like 1.1b3 comes
before the release version 1.1; it should and I think pkgsrc-dewey
recognizes this if it's presented correctly, but either some old
revisions don't present it correctly or your script did the wrong
thing.

 o  In one case, the use of hex digits in version numbers.

There are also a couple of cases where mistakes transcribing version
numbers into pkgsrc resulted in apparent downgrades, either
immediately or downstream.

There were a couple of cases where upgrades of one of the above forms
failed to make it into CHANGES, which is undesirable but irrelevant to
(Continue reading)

David Holland | 3 Jul 03:05 2008
On Wed, Jul 02, 2008 at 02:50:06PM +0300, Aleksey Cheusov wrote:
 > > upstream realized the problem and released 0.60, which I put in pkgsrc
 > > yesterday.
 > 
 > This is good, but the real problem is not with this particular package
 > but with that there is no control for downgrades at all.
 > Today I've filled a PR about this problem.

What do you mean by this? Your PR wasn't very clear. (Also see the
other message I just posted.)

--

-- 
David A. Holland
dholland <at> netbsd.org


Gmane