Thanks Oded. Just to be clear I wasn't talking about getting rid of the include folder, just the include/linux subfolder.
________________________________________
From: Oded Gabbay [oded.gabbay@xxxxxxxxx]
Sent: October 18, 2015 6:51 AM
To: Bridgman, John
Cc: Maling list - DRI developers; Alex Deucher
Subject: Re: [hsakmt] hsakmt organization and formal releases
On Sun, Oct 18, 2015 at 1:14 PM, Bridgman, John <John.Bridgman@xxxxxxx> wrote:
> Hi Oded,
>
> Looks good. We now have a nice automated build/test system running internally,
> I imagine automake/autoconf should be able to fit OK into that (although I guess
> it might trigger the usual religious war about build tools :))
>
> re: #2, IIRC we used to do the even/odd numbering on minor not micro, is that
> a deliberate change ?
>
Actually, the whole version numbering in hsakmt is confusing...
Up until now, there were:
1. HSAKMT_VERSION_MAJOR/HSAKMT_VERSION_MINOR in hsakmttypes.h. I have
no idea for what those defines are used - probably left-overs from
windows thunk design. Maybe Paul knows.
2. KFD_IOCTL_MAJOR_VERSION/KFD_IOCTL_MINOR_VERSION in kfd_ioctl.h.
That's left-overs from the time we returned those defines to the HSA
RT layer. Now, we get those from the amdkfd using an IOCTL call. It
allows the HSA RT to know the features that amdkfd provides. I think
there were discussions of replacing them with some bitmask field, but
I don't know the current status.
Therefore, I didn't want to rely on any of the above, so I created a
new system in configure.ac that will be used just to provide numbers
for the sake of releases, as the two existing methods don't change
according to releases.
In my scheme, major will be used for ABI breakage and/or when minor
gets to big numbers, minor for important releases and micro for
differentiating between a released version and in-development version.
e.g. 1.0.4 - released version
1.0.5 - version in development.
1.0.6 - next released version.
1.0.7 - next version in development.
1.1.0 - next important/big release
1.1.1 - development tree after the release
> I'm sure I'll get questions about the hsakmt/hsakmt folder structure but if you
> get rid of the src folder not sure what would be better. Just curious, why not keep
> build files at top level then have src/include folders underneath ?
>
This folder structure is standard when using autoconf tools. So you
have a root folder, i.e. hsakmt, then you have the folder which
contains sources (and headers), which is the same name. You can have
other folders at this level, for "tests", "docs", etc. Also, folders
are created automatically at this level, e.g. autom4te.cache
Under the "second" hsakmt folder, you have your project sources, in
any structure you want. The resulting build outputs (objects,
libraries, etc.) are included in those folders and in hidden .deps,
.libs folders. They are ignored using .gitignore files.
I did it according to the pixman library which I now also maintain.
Initially, I even deleted the include folder, but I returned it to
make the change less radical for you (see below).
> That include/linux folder has been bugging me for a while so we'll probably get
> rid of it at some point. Don't remember the history so unless someone else does...
>
The reason for the include folder is to map it directly to the
internal source control tool you use, so that it can be shared between
windows and linux development.
The reason for include/linux is to separate linux-only files from
windows-only files.
As I said above, I have no problem removing these, but I feared it
might be too radical for you...
If you want to see how it will look like without the include folder,
check out http://cgit.freedesktop.org/amd/hsakmt/tree/?id=e8a6286922e9add2d34ca29fd2b3c6b3ace35f69
Thanks,
Oded
> Everything else looks good. Thanks !!
> ________________________________________
> Original Message
> From: Oded Gabbay
> Sent: Sunday, October 18, 2015 2:39 AM
> To: Bridgman, John
> Cc: Maling list - DRI developers; Alex Deucher
> Subject: Re: [hsakmt] hsakmt organization and formal releases
>
>
> On Fri, Oct 9, 2015 at 7:46 PM, Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
>> On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay <oded.gabbay@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> I had some time during the recent local holidays, so I thought I
>>> improve the hsakmt library in terms of releases:
>>>
>>> 1. I added automake/autoconf files to standardize the package to be
>>> created using configure/make/make install.
>>>
>>> 2. I created a very simple scheme of numbering so we could track releases.
>>>
>>> 3. I created a git repository under freedesktop.org amd's folder that
>>> will hold hsakmt code (instead of using my private git repo). You can
>>> clone the new repo from: git://anongit.freedesktop.org/amd/hsakmt
>>>
>>> 4. I created two new sub-components in freedesktop.org bugzilla, under
>>> DRI, for hsakmt and amdkfd, so bugs can be filed correctly.
>>>
>>> As part of point 1, I rearranged the layout of the source files a bit,
>>> although I kept the formation of the include files so it would be easy
>>> to use inside AMD :)
>>>
>>> I would like to get (positive) feedback on this, and then I will
>>> create the first official release and also F22, F23 and F24 (rawhide)
>>> rpm packages that will be part of the distribution.
>>>
>>> As a reminder, this repository will be used to manage only the
>>> upstream version of hsakmt. Private/non-yet-upstreamed releases of AMD
>>> are done in GitHub.
>>
>> Looks good to me! thanks,
>>
>> Alex
>>
>>>
>>> Thanks,
>>>
>>> Oded
>
> John, any comment from you ?
> If not, I assume I can go ahead.
>
> Oded
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
