Thank you for the reply! I am happy to provide that info= rmation. To be clear, what are you looking for when you say "cha= nge numbers"? The 5-digit number from Gerrit? The Change-I= D hash from the commit? Or the sha of the commit to master itself?

Thank you again!

-Ben

From: Stephan Wiesand <s= tephan.wiesand@desy.de>
Sent: Friday, March 3, 2023 10:12 AM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Pulling up changes to stable

Hi Ben,

> On 3. Mar 2023, at 18:13, Ben Huntsman <ben@huntsmans.net> wrote= :
>
> Hi there!
>    Thank you for accepting the patches I submitted to g= et OpenAFS working on AIX 7.2-7.3, as well as the previous ones!

thank you for whipping those up.

>    Now that they're all there in the master branch, wha= t needs to be done to pull them up into an upcoming stable branch?

These changes are on my list of things I want to get into stable. I'm just = slow.

>   I read the GitDevelopers page, but is it ok for anyone to = push patches to Gerrit for an upcoming stable, or is there some additional = review process?

In principle it's ok, provided that those patches are clean cherry-picks fr= om master. In practice, it causes extra work if a change pulled up like thi= s touches a file already modified by any other change in the queue. In addi= tion, you'll sometimes (or rather often) find that the change from master doesn't apply cleanly to stable, a= nd either needs to be modified or (preferrably) be supplemented by more cha= nges from master not yet on stable.

Mind you, you're absolutely free to submit those pull-ups yourself. The mos= t appreciated way you can help though is to provide a list of change number= s you'd like to see in an upcoming stable release. And keep poking...

Best regards,
        Stephan

>
>    Thank you much!
>
> -Ben

--
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany

--_000_MWHPR0701MB367405475C46702FC6847A16A7B39MWHPR0701MB3674_-- From kaduk@mit.edu Sun Mar 5 02:37:44 2023 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sat, 4 Mar 2023 18:37:44 -0800 Subject: [OpenAFS-devel] Pulling up changes to stable In-Reply-To: References: <7D5EFB82-FB08-4495-8BC1-DA685CDB7880@desy.de> Message-ID: The change number would be the 5-digit number from gerrit, but any of those would work well enough to identify what you want. -Ben On Fri, Mar 03, 2023 at 11:36:47PM +0000, Ben Huntsman wrote: > Hi Stephan! > Thank you for the reply! I am happy to provide that information. To be clear, what are you looking for when you say "change numbers"? The 5-digit number from Gerrit? The Change-ID hash from the commit? Or the sha of the commit to master itself? > > Thank you again! > > -Ben > > ________________________________ > From: Stephan Wiesand > Sent: Friday, March 3, 2023 10:12 AM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Pulling up changes to stable > > Hi Ben, > > > On 3. Mar 2023, at 18:13, Ben Huntsman wrote: > > > > Hi there! > > Thank you for accepting the patches I submitted to get OpenAFS working on AIX 7.2-7.3, as well as the previous ones! > > thank you for whipping those up. > > > Now that they're all there in the master branch, what needs to be done to pull them up into an upcoming stable branch? > > These changes are on my list of things I want to get into stable. I'm just slow. > > > I read the GitDevelopers page, but is it ok for anyone to push patches to Gerrit for an upcoming stable, or is there some additional review process? > > In principle it's ok, provided that those patches are clean cherry-picks from master. In practice, it causes extra work if a change pulled up like this touches a file already modified by any other change in the queue. In addition, you'll sometimes (or rather often) find that the change from master doesn't apply cleanly to stable, and either needs to be modified or (preferrably) be supplemented by more changes from master not yet on stable. > > Mind you, you're absolutely free to submit those pull-ups yourself. The most appreciated way you can help though is to provide a list of change numbers you'd like to see in an upcoming stable release. And keep poking... > > Best regards, > Stephan > > > > > Thank you much! > > > > -Ben > > > -- > Stephan Wiesand > DESY - DV - > Platanenallee 6 > 15738 Zeuthen, Germany > > > From Tracy.DiMarcoWhite@gs.com Mon Mar 6 20:52:06 2023 From: Tracy.DiMarcoWhite@gs.com (Di Marco White, Tracy J) Date: Mon, 6 Mar 2023 20:52:06 +0000 Subject: [OpenAFS-devel] 2023 AFS Technology Workshop Message-ID: Dear community, The organizers of the 2023 AFS Technology Workshop invite you to participat= e in this year's virtual workshop. The workshop will be held Monday June 12= th through Wednesday June 14th with presentations, panels, and site reports= each day from 9:30 am EDT until 3:00 pm EDT, and themed community discussi= on time (hallway track) Tuesday and Wednesday at 8:30am EDT and Monday, Tue= sday, and Wednesday after presentations complete for the day. Important dates: Call for Presentations: Presentation proposals can be submitted from no= w until April 18th. Please see https://workshop.openafs.org/afsbpw23/cfp/= for details. Site Report Submissions: Site Reports will be accepted until the availa= ble site report slots are filled. Site reports are 5 to 15 minute introdu= ctions to your personal or organizational use of AFS technologies. Site r= eports help build a shared community and provide an ice breaker for virtual= hallway conversations. Registration: Registration will be available starting May 1st. Messages will be sent every two weeks from now until the conference as remi= nders of upcoming deadlines and to provide additional information as it bec= omes available. The 2023 AFS Technology Workshop organizers ________________________________ Your Personal Data: We may collect and process information about you that m= ay be subject to data protection laws. For more information about how we us= e and disclose your personal data, how we protect your information, our leg= al basis to use your information, your rights and who you can contact, plea= se refer to: www.gs.com/privacy-notices From mmeffie@sinenomine.net Thu Mar 9 21:11:31 2023 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 9 Mar 2023 16:11:31 -0500 Subject: [OpenAFS-devel] OpenAFS Release Team weekly meeting Message-ID: <20230309161131.4e1bfb27@lana> OpenAFS Release Team weekly meeting Date: March 09, 2023 Participants: - Stephan Wiesand, OpenAFS Release Manager - Ben Kaduk - Cheyenne Wills - Michael Meffie The OpenAFS Release Team meetings are held on IRC each Thursday at 12:00 noon Eastern Time (local time) on the #openafs-releaseteam channel of Libera.Chat. Stable (1.8.x) ============== US switches to daylight savings time this weekend. Stephan said the meeting time will be the same local time for US participants next week (12 EDT/9 PDT). Cheyenne reports he is testing patches for Linux 6.3rc support. Development (1.9.x/master) ========================== Mike requested 12374, 12375, 12376 to be merged on master so they be considered for 1.8.x 12374 libadmin: parse rxstat_* command line args with libcmd 12375 libadmin: add afsclient_TokenPrint function 12376 libadmin: add rxstat_* -localauth option Recent Changes ============== Updated for 'openafs-stable-1_8_x' branch since 2023-03-02: 15300 rx: Do not ignore RXS_* op errors 15334 rx: Revert RXS_DestroyConnection()'s return type 15330 Do not merge: Check buildbot verification on stable Merged onto 'master' branch since 2023-03-02: 15312 AIX: Avoid including net/netisr.h on AIX 7.2 and above 15311 comerr: Update rule for compile_et 15310 configure: Add platform rs_aix73 15280 rx: Fix rx_atomic.h style nits 15279 tests: Add unit tests for rx_atomic.h Updated for 'master' branch since 2023-03-02: 14863 vol: Initialize vnode dv and inode dv consistently 15207 vol: Optionally remove salvaged RW volumes 15206 vol: Introduce VFakeAttachVolumeByName 15205 vol: Consolidate common vol header delete logic 15204 vol: Make FSYNC operations optional in VPurgeVolume 15203 DAFS: Avoid FSYNC operations when fileserver is down for salvage 15202 bozo: bos salvage should invoke dasalvager on DAFS 15201 vol: Use VolumeExternalName_r more consistently 15200 vol: Introduce LogMaybe 14862 salvager: Don't fix vnode dv of new regular files 15089 bozo: Parse command lines with cmd_Tokenize() and cmd_Split() 15088 cmd: Introduce cmd_Tokenize() and cmd_Split() 15098 backup: Make backup tests build again 15097 backup: Remove obsolete test programs 15336 rx: Use _CLASS_RECV_CBUF in rxi_ReadPacket 15340 doc: Mention negative host ACL behavior 13613 rx: Use sendmmsg when available 13612 rx: Introduce rxi_SendPacketDgrams 13611 rx: Introduce 'flags' argument to rxi_SendList 13610 rx: Use recvmmsg when available 15339 rx: Sort channels by busy-ness in rx_NewCall 15338 rx: Rename rx_NewCall 'i' to 'channel' 15337 rx: Introduce rxi_ExpandReceivePacket 13609 rx: Introduce rxi_Read/ReceivePacketList 13608 rx: Split out rxi_ReceivePacketConn 13607 rx: Split out rxi_ReceivePacketCall 14309 rx: Change conn->lastBusy to use atomics 13606 rx: Split out invoke_justReceived 13605 rx: Split out rxi_ReceivePacketGlobal 13604 rx: Refactor rxi_ReceivePacket destructors 13601 rx: Split rxi_ReadPacket into three functions 15087 tests: Add cmd_ParseLine() checks 15335 cmd: Do not leak tokens in cmd_ParseLine() 15086 cmd: Do not leak param in cmd_Parse() 14596 auth: refactor GenericAuth() 15322 afsio: Introduce -auth-as From mmeffie@sinenomine.net Thu Mar 16 21:46:30 2023 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 16 Mar 2023 16:46:30 -0400 Subject: [OpenAFS-devel] OpenAFS Release Team weekly meeting Message-ID: <20230316164630.37688074@lana> OpenAFS Release Team weekly meeting Date: March 16, 2023 Participants: - Stephan Wiesand, OpenAFS Release Manager - Ben Kaduk - Cheyenne Wills - Michael Meffie - Mark Vitale The OpenAFS Release Team meetings are held on IRC each Thursday at 12:OO noon Eastern on the #openafs-releaseteam channel of Libera.Chat. Stable (1.8.x) ============== Merged on the stable branch: 15300 rx: Do not ignore RXS_* op errors 15334 is currently the top commit in gerrit for 1.8.x. That is a linear set of changes for 1.8.x. Mike will gather the list of gerrits from Ben Huntsman for AIX support, already merged on master. Development (1.9.x/master) ========================== Cheyenne submitted changes for linux 6.3 support. To be reviewed. 15346 linux: detect and use filelock.h 15348 linux 6.3 idmap changes 15347 Linux 6.3: Test for mnt_idmap in inode_operations Recent Changes ============== Updated for 'openafs-stable-1_8_x' branch since 2023-03-09: 15300 rx: Do not ignore RXS_* op errors Merged onto 'master' branch since 2023-03-09: 15097 backup: Remove obsolete test programs Updated for 'master' branch since 2023-03-09: 13601 rx: Split rxi_ReadPacket into three functions 15337 rx: Introduce rxi_ExpandReceivePacket 15336 rx: Use _CLASS_RECV_CBUF in rxi_ReadPacket 13621 rx: Use SO_REUSEPORT for multiple listener threads 13620 rx: Split out rxi_BindSocket for userspace 15123 viced: Avoid blocking in multi_Rx 15117 viced: Update host package lock precedence 15351 Add vos and pts fallback to server config 12586 bozo: Do not create client directory and symlinks 14891 doc: refactor generate-man 14892 doc: optimize generate-man 14893 doc: parallelize generate-man 15067 doc: Use make to build the man pages 13619 rx: Defer rxi_Start calls during rxi_WriteProc 15350 vol: Remove remaining AFS_DEMAND_ATTACH_UTIL 15349 rx: Avoid unnecessary locking in rxi_ReapConnections 14951 rx: prevent leak of cache manager NAT ping rx_connections 15135 rx: Reap client conns in rxi_ReapConnections 15346 linux: detect and use filelock.h 15348 linux 6.3 idmap changes 15347 Linux 6.3: Test for mnt_idmap in inode_operations 15343 xdr: Avoid xdr_string maxsize check when freeing 15345 viced: GetRights negative ACEs are superior to positive ACEs 15344 libacl: introduce acl_checkRights2 15340 doc: Mention negative host ACL behavior 13617 rx: Refactor rxi_WriteProc error handling 13616 rx: Introduce rxi_WaitForTransmitWindow 13615 viced: Allow multiple rx listeners 13614 rx: Allow multiple rx listeners for pthreads 15342 tests: Make src/tests buildable 15341 tests: Remove snprintf.c from src/tests 15207 vol: Optionally remove salvaged RW volumes 15206 vol: Introduce VFakeAttachVolumeByName 15205 vol: Consolidate common vol header delete logic 15203 DAFS: Avoid FSYNC operations when fileserver is down for salvage 15204 vol: Make FSYNC operations optional in VPurgeVolume 15201 vol: Use VolumeExternalName_r more consistently 15202 bozo: bos salvage should invoke dasalvager on DAFS 15200 vol: Introduce LogMaybe 14862 salvager: Don't fix vnode dv of new regular files 14863 vol: Initialize vnode dv and inode dv consistently 15089 bozo: Parse command lines with cmd_Tokenize() and cmd_Split() 15088 cmd: Introduce cmd_Tokenize() and cmd_Split() From Tracy.DiMarcoWhite@gs.com Tue Mar 21 21:59:17 2023 From: Tracy.DiMarcoWhite@gs.com (Di Marco White, Tracy J) Date: Tue, 21 Mar 2023 20:59:17 +0000 Subject: [OpenAFS-devel] 2023 AFS Technology Workshop In-Reply-To: References: Message-ID: Dear community, The organizers of the 2023 AFS Technology Workshop invite you to participat= e in this year's virtual workshop. The workshop will be held Monday June 12= th through Wednesday June 14th with presentations, panels, and site reports= each day from 9:30 am EDT until 3:00 pm EDT, and themed community discussi= on time (hallway track) Tuesday and Wednesday at 8:30am EDT and Monday, Tue= sday, and Wednesday after presentations complete for the day. Important dates: Call for Presentations: Presentation proposals can be submitted from no= w until April 18th. Please see https://workshop.openafs.org/afsbpw23/cfp/= for details. Site Report Submissions: Site Reports will be accepted until the availa= ble site report slots are filled. Site reports are 5 to 15 minute introdu= ctions to your personal or organizational use of AFS technologies. Site r= eports help build a shared community and provide an ice breaker for virtual= hallway conversations. Registration: Registration will be available starting May 1st. Messages will be sent every two weeks from now until the conference as remi= nders of upcoming deadlines and to provide additional information as it bec= omes available. The 2023 AFS Technology Workshop organizers ________________________________ Your Personal Data: We may collect and process information about you that m= ay be subject to data protection laws. For more information about how we us= e and disclose your personal data, how we protect your information, our leg= al basis to use your information, your rights and who you can contact, plea= se refer to: www.gs.com/privacy-notices From ben@huntsmans.net Wed Mar 29 17:29:28 2023 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 29 Mar 2023 16:29:28 +0000 Subject: [OpenAFS-devel] Pulling up changes to stable In-Reply-To: References: <7D5EFB82-FB08-4495-8BC1-DA685CDB7880@desy.de> Message-ID: --_000_MWHPR0701MB36749B2A8BF4ABE755B47091A7899MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there! Thanks for the clarification, and apologies for the delay. Below are th= e 5-digit change numbers from Gerrit that we'd need to pull up to a stable = branch in order to fully support AIX: 15107 15116 15110 15112 15113 15114 15108 15119 15118 15122 15144 15145 15143 15146 15142 15310 15311 15312 Is there anything I can help do to get those incorporated into the next = release? Thank you so much! -Ben ________________________________ From: Benjamin Kaduk Sent: Saturday, March 4, 2023 6:37 PM To: Ben Huntsman Cc: Stephan Wiesand ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Pulling up changes to stable The change number would be the 5-digit number from gerrit, but any of those would work well enough to identify what you want. -Ben On Fri, Mar 03, 2023 at 11:36:47PM +0000, Ben Huntsman wrote: > Hi Stephan! > Thank you for the reply! I am happy to provide that information. To = be clear, what are you looking for when you say "change numbers"? The 5-di= git number from Gerrit? The Change-ID hash from the commit? Or the sha of= the commit to master itself? > > Thank you again! > > -Ben > > ________________________________ > From: Stephan Wiesand > Sent: Friday, March 3, 2023 10:12 AM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Pulling up changes to stable > > Hi Ben, > > > On 3. Mar 2023, at 18:13, Ben Huntsman wrote: > > > > Hi there! > > Thank you for accepting the patches I submitted to get OpenAFS worki= ng on AIX 7.2-7.3, as well as the previous ones! > > thank you for whipping those up. > > > Now that they're all there in the master branch, what needs to be do= ne to pull them up into an upcoming stable branch? > > These changes are on my list of things I want to get into stable. I'm jus= t slow. > > > I read the GitDevelopers page, but is it ok for anyone to push patche= s to Gerrit for an upcoming stable, or is there some additional review proc= ess? > > In principle it's ok, provided that those patches are clean cherry-picks = from master. In practice, it causes extra work if a change pulled up like t= his touches a file already modified by any other change in the queue. In ad= dition, you'll sometimes (or rather often) find that the change from master= doesn't apply cleanly to stable, and either needs to be modified or (prefe= rrably) be supplemented by more changes from master not yet on stable. > > Mind you, you're absolutely free to submit those pull-ups yourself. The m= ost appreciated way you can help though is to provide a list of change numb= ers you'd like to see in an upcoming stable release. And keep poking... > > Best regards, > Stephan > > > > > Thank you much! > > > > -Ben > > > -- > Stephan Wiesand > DESY - DV - > Platanenallee 6 > 15738 Zeuthen, Germany > > > --_000_MWHPR0701MB36749B2A8BF4ABE755B47091A7899MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

Thanks for the clarification, and apologies for the delay= . Below are the 5-digit change numbers from Gerrit that we'd need to = pull up to a stable branch in order to fully support AIX:

15107

15116

15110

15112

15113

15114

15108

15119

15118

15122

15144

15145

15143

15146

15142

15310

15311

15312

Is there anything I can help do to get those incorporated into= the next release?

Thank you so much!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Saturday, March 4, 2023 6:37 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Stephan Wiesand <stephan.wiesand@desy.de>; openafs-devel@o= penafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Pulling up changes to stable

The change number would be the 5-digit number from= gerrit, but any of those
would work well enough to identify what you want.

-Ben

On Fri, Mar 03, 2023 at 11:36:47PM +0000, Ben Huntsman wrote:
> Hi Stephan!
>    Thank you for the reply! I am happy to provide= that information. To be clear, what are you looking for when you say= "change numbers"? The 5-digit number from Gerrit? Th= e Change-ID hash from the commit? Or the sha of the commit to master = itself?
>
>    Thank you again!
>
> -Ben
>
> ________________________________
> From: Stephan Wiesand <stephan.wiesand@desy.de>
> Sent: Friday, March 3, 2023 10:12 AM
> To: Ben Huntsman <ben@huntsmans.net>
> Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
> Subject: Re: [OpenAFS-devel] Pulling up changes to stable
>
> Hi Ben,
>
> > On 3. Mar 2023, at 18:13, Ben Huntsman <ben@huntsmans.net> = wrote:
> >
> > Hi there!
> >    Thank you for accepting the patches I submitted= to get OpenAFS working on AIX 7.2-7.3, as well as the previous ones!
>
> thank you for whipping those up.
>
> >    Now that they're all there in the master branch= , what needs to be done to pull them up into an upcoming stable branch?
>
> These changes are on my list of things I want to get into stable. I'm = just slow.
>
> >   I read the GitDevelopers page, but is it ok for anyon= e to push patches to Gerrit for an upcoming stable, or is there some additi= onal review process?
>
> In principle it's ok, provided that those patches are clean cherry-pic= ks from master. In practice, it causes extra work if a change pulled up lik= e this touches a file already modified by any other change in the queue. In= addition, you'll sometimes (or rather often) find that the change from master doesn't apply cleanly to stable, a= nd either needs to be modified or (preferrably) be supplemented by more cha= nges from master not yet on stable.
>
> Mind you, you're absolutely free to submit those pull-ups yourself. Th= e most appreciated way you can help though is to provide a list of change n= umbers you'd like to see in an upcoming stable release. And keep poking...<= br> >
> Best regards,
>         Stephan
>
> >
> >    Thank you much!
> >
> > -Ben
>
>
> --
> Stephan Wiesand
> DESY - DV -
> Platanenallee 6
> 15738 Zeuthen, Germany
>
>
>

--_000_MWHPR0701MB36749B2A8BF4ABE755B47091A7899MWHPR0701MB3674_-- From ben@huntsmans.net Wed Mar 29 18:38:39 2023 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 29 Mar 2023 17:38:39 +0000 Subject: [OpenAFS-devel] Build system help Message-ID: --_000_MWHPR0701MB36743F10343869B23E87F0C1A7899MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone- I had a thought that it would be interesting to see if the AIX build cou= ld be set up to work with either GCC or XLC, whereas currently it's pretty = hard-coded around XLC. Furthermore, builds with GCC don't work as extra th= ings have to be done when building the kernel extension. However, not being intimately familiar with the build system, would anyo= ne have a suggestion as to where to start? I'm looking at src/cf/sysname.m= 4 and see that based on the sysname value selected there, certain compiler = selections and options get defined in src/cf/osconf.m4. However, we probab= ly don't want to define sysnames like rs_aix72_gcc and rs_aix72_xlc. Would= it be best to add more complex logic to osconf.m4 to detect xlc or gcc and= set the variables there accordingly, or would there be a more appropriate = place? Thank you! -Ben --_000_MWHPR0701MB36743F10343869B23E87F0C1A7899MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone-

I had a thought that it would be interesting to see if the AIX= build could be set up to work with either GCC or XLC, whereas currently it= 's pretty hard-coded around XLC. Furthermore, builds with GCC don't w= ork as extra things have to be done when building the kernel extension.

However, not being intimately familiar with the build sys= tem, would anyone have a suggestion as to where to start? I'm looking= at src/cf/sysname.m4 and see that based on the sysname value selected ther= e, certain compiler selections and options get defined in src/cf/osconf.m4. However, we probably don't want to define sysna= mes like rs_aix72_gcc and rs_aix72_xlc. Would it be best to add more = complex logic to osconf.m4 to detect xlc or gcc and set the variables there= accordingly, or would there be a more appropriate place?

Thank you!

-Ben

--_000_MWHPR0701MB36743F10343869B23E87F0C1A7899MWHPR0701MB3674_-- From cwills@sinenomine.net Wed Mar 29 18:56:25 2023 From: cwills@sinenomine.net (Cheyenne Wills) Date: Wed, 29 Mar 2023 11:56:25 -0600 Subject: [OpenAFS-devel] Build system help In-Reply-To: References: Message-ID: <20230329115625.491271e3.cwills@sinenomine.net> On Wed, 29 Mar 2023 17:38:39 +0000 Ben Huntsman wrote: > Hi everyone- > I had a thought that it would be interesting to see if the AIX > build could be set up to work with either GCC or XLC, whereas > currently it's pretty hard-coded around XLC. Furthermore, builds > with GCC don't work as extra things have to be done when building the > kernel extension. > > However, not being intimately familiar with the build system, > would anyone have a suggestion as to where to start? I'm looking at > src/cf/sysname.m4 and see that based on the sysname value selected > there, certain compiler selections and options get defined in > src/cf/osconf.m4. However, we probably don't want to define sysnames > like rs_aix72_gcc and rs_aix72_xlc. Would it be best to add more > complex logic to osconf.m4 to detect xlc or gcc and set the variables > there accordingly, or would there be a more appropriate place? > > Thank you! > > -Ben > The selection of the compiler can be controlled via "CC=" on a command line when running configure. From there, within the autoconf scripts you would need to check for the specific compiler being used and set the flags as needed (take a look at linux and the use of gcc vs clang as a possible model). -- Cheyenne Wills cwills@sinenomine.net