[pve-devel] [PATCH ha-manager] Add make dsc target

[Thomas Lamprecht]

On 1/7/19 3:14 PM, Rhonda D'Vine wrote:
>     Hi.
> 
> On 1/7/19 2:25 PM, Thomas Lamprecht wrote:
>> On 1/7/19 1:51 PM, Rhonda D'Vine wrote:
>>> Pull out the build dir creation into its own target, and add the "dsc"
>>> target.  Also get some static information from the packaging.
>>>
>>> Signed-off-by: Rhonda D'Vine <rhonda at proxmox.com>
>>> ---
>>>  Makefile | 31 +++++++++++++++++++++----------
>>>  1 file changed, 21 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 89fa8a4..9b2b7c0 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1,14 +1,16 @@
>>> -VERSION=2.0
>>> -PACKAGE=pve-ha-manager
>>> +VERSION != dpkg-parsechangelog -Sversion | cut -d- -f1
>>> +PACKAGE != dpkg-parsechangelog -Ssource
>>>  SIMPACKAGE=pve-ha-simulator
>>> -PKGREL=6
>>> +PKGREL  != dpkg-parsechangelog -Sversion | cut -d- -f2
>> 1. this has nothing to do with the dsc make-target addition
>> 2. I'd like to keep this as is for now, the mix for hardcoded (simpackage) and
>>    computed looks a bit weird and I do not see a real advantage for simple
>>    versioning schemas as this is (in contrary to, e.g., the pve-edk2-firmware one)
>>    they may even get wrong if the versioning schema (for, e.g., a backport) or
>>    package name changes.
> 
> 
>  Okay, I can see the point with the mixed parts. Actually I realized
> that there isn't even a need to define SIMPACKAGE because it's only used
> in the lintian call - which actually should be based on the created
> .changes file instead, and thus would pick up all binary packages
> regardless. That would also be something that could get done across all
> packages in the long run to reduce complexity and eliminate specific
> differences between the packages.

sound OK to me.

> 
> 
>> Further, a simple "make" invocation gives me a recursive package build loop,
>> did you test this?
> 
> 
>  Yes I did, that puzzles me. But I now see that you are using -j8, my
> build test host only got one CPU, so it didn't try to build DEB and
> SIMDEB in parallel, and building DEB produced SIMDEB.
> 
> 
>  My bad, will clean that up to make it build on multithreaded build
> systems too.

great!

> What's interesting is: I didn't change that part. That
> should have failed for you before already, without my patch. I don't see
> how it would have affected that.

I immediately (re)checked this too and it works without your patch on my
multicore build VM just fine. May still just be a existing issue which got
exposed through your change, though.

cheers,
Thomas