From ingemar.aberg at oracle.com Mon Jun 1 09:12:48 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Mon, 01 Jun 2015 09:12:48 +0000 Subject: hg: build-infra/jdk9: Fixed BUILD_TOOLCHAIN to handle SYSROOT flags better Message-ID: <201506010912.t519CmBs017489@aojmv0008.oracle.com> Changeset: 1e4f41790070 Author: iaberg Date: 2015-06-01 11:04 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/rev/1e4f41790070 Fixed BUILD_TOOLCHAIN to handle SYSROOT flags better ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! make/common/NativeCompilation.gmk From ingemar.aberg at oracle.com Mon Jun 1 09:13:11 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Mon, 01 Jun 2015 09:13:11 +0000 Subject: hg: build-infra/jdk9/hotspot: Fixed BUILD_TOOLCHAIN to handle SYSROOT flags better Message-ID: <201506010913.t519DBo3017590@aojmv0008.oracle.com> Changeset: f475fdbef651 Author: iaberg Date: 2015-06-01 11:04 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/hotspot/rev/f475fdbef651 Fixed BUILD_TOOLCHAIN to handle SYSROOT flags better ! makefiles/GensrcAdlc.gmk From ingemar.aberg at oracle.com Mon Jun 1 09:37:12 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Mon, 01 Jun 2015 09:37:12 +0000 Subject: hg: build-infra/jdk9: Fixed BUILD_TOOLCHAIN* to work with cross compilation Message-ID: <201506010937.t519bCs7022372@aojmv0008.oracle.com> Changeset: 84bdc83d19e6 Author: iaberg Date: 2015-06-01 11:34 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/rev/84bdc83d19e6 Fixed BUILD_TOOLCHAIN* to work with cross compilation ! make/common/NativeCompilation.gmk From ingemar.aberg at oracle.com Tue Jun 2 12:17:55 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Tue, 02 Jun 2015 12:17:55 +0000 Subject: hg: build-infra/jdk9: Enabled cross compiling (arm) Message-ID: <201506021217.t52CHtwL018271@aojmv0008.oracle.com> Changeset: 024ac71466c0 Author: iaberg Date: 2015-06-02 14:12 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/rev/024ac71466c0 Enabled cross compiling (arm) ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in From ingemar.aberg at oracle.com Tue Jun 2 12:18:18 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Tue, 02 Jun 2015 12:18:18 +0000 Subject: hg: build-infra/jdk9/hotspot: 2 new changesets Message-ID: <201506021218.t52CIJ4o018396@aojmv0008.oracle.com> Changeset: 5d845cd61327 Author: iaberg Date: 2015-06-02 14:09 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/hotspot/rev/5d845cd61327 Remove jre from dist paths, enable alternative source for jni_md.h ! makefiles/Dist.gmk Changeset: a8fdf52e0cff Author: iaberg Date: 2015-06-02 14:10 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/hotspot/rev/a8fdf52e0cff Fixed new build for arm(32) ! makefiles/Common.gmk ! makefiles/CompileJvm.gmk ! makefiles/CompileLibraries.gmk ! makefiles/GensrcAdlc.gmk ! makefiles/SA.gmk From magnus.ihse.bursie at oracle.com Wed Jun 3 13:12:34 2015 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Wed, 03 Jun 2015 13:12:34 +0000 Subject: hg: build-infra/jdk9/hotspot: Small fixes. Removed debug output. Message-ID: <201506031312.t53DCY5j019822@aojmv0008.oracle.com> Changeset: 9803fee0084f Author: ihse Date: 2015-06-03 15:14 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/hotspot/rev/9803fee0084f Small fixes. Removed debug output. ! makefiles/CompileLibraries.gmk ! makefiles/GensrcAdlc.gmk ! makefiles/SA.gmk From volker.simonis at gmail.com Fri Jun 12 17:36:59 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Jun 2015 19:36:59 +0200 Subject: RFR: Enable new HS build on linux/ppc64 Message-ID: Hi, and sorry for the delay:) Here's a patch to enable the new HS build on Linux/ppc64: http://cr.openjdk.java.net/~simonis/webrevs/2015/new_hs_build_on_linux_ppc64/ The compare.sh script is pretty cool and I at least managed to get the same symbols in both the old and the new libjvm also all the fulldump differs: Directory structure...Identical! File names...Identical! Permissions...Identical! File types...Identical! General files... Jar files... Libraries... Binary : Size : Symbols : Deps : Fulldump : Disass : * diff *: : : :* 126*: : ./lib/ppc64/libjsig.so * diff *: : : :* 2745330*:* 9939*: ./lib/ppc64/server/libjvm.so REGRESSIONS FOUND! But I think that's OK for now:) OK to push? Thanks, Volker From volker.simonis at gmail.com Fri Jun 12 17:50:54 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Jun 2015 19:50:54 +0200 Subject: -static-libgcc vs. -Wl,-Bstatic -lgcc Message-ID: Hi, while porting the new HS build to linux/ppc64 I saw that we are now setting some link options unconditionally trough the $(LIBCXX) variable from the top-level spec.gmk (whihc is good :). With the default configuration, this variable will contain the value "-Wl,-Bstatic -lstdc++ -lgcc" but this can be changed by setting --with-stdc++lib=dynamic. Nevertheless, we still set "-static-libgcc" unconditionally in Common.gmk Now there's one think I don't understand (and which isn't related to ppc64). I thought "-static-libgcc" and "-Wl,-Bstatic -lgcc" should be equivalent options, but apparently they aren?t. For the new build we use "-Wl,-Bstatic -lstdc++ -lgcc" and additionally set "-static-libgcc". I thought it should be possible to remove the "-static-libgcc" setting from the new HS build system (because the question static/dynamic linking of libstdc++ should be decided at configure time with the --with-stdc++lib option. But this will produce a different results. Summing it up: old build: -static-libgcc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -ldl -lpthread is the same as new build: -static-libgcc -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread but not the same as the new build without "-static-libgcc": -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread which dynamically links ibgcc_s.so.1 (at least on x86_64) It turns out (if you run gcc with '-v') that with "-static-libgcc" the command line expands to: -lgcc -lgcc_eh -lc -lgcc -lgcc_eh which will all be statically linked. while without "-static-libgcc" it expands to: -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed and dynamically links libgcc_s.so.1 (at least on x86_64 but not on ppc64). The problem is that "libgcc_s.so.1" is only available as shared library so we can't statically link it even if we want. So should we move "-static-libgcc" to libraries.m4 to the place where we detect whether to use --with-stdc++lib=static/dynamic because we apparently can't live without it if we still want to link libgcc statically? Regards, Volker From magnus.ihse.bursie at oracle.com Fri Jun 12 17:51:45 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 19:51:45 +0200 Subject: RFR: Enable new HS build on linux/ppc64 In-Reply-To: References: Message-ID: <67C25004-C971-4A80-AF9E-0C92179B84EF@oracle.com> Looks good! Push away! :) /Magnus > 12 jun 2015 kl. 19:36 skrev Volker Simonis : > > Hi, > > and sorry for the delay:) > > Here's a patch to enable the new HS build on Linux/ppc64: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/new_hs_build_on_linux_ppc64/ > > The compare.sh script is pretty cool and I at least managed to get the > same symbols in both the old and the new libjvm also all the fulldump > differs: > > Directory structure...Identical! > File names...Identical! > Permissions...Identical! > File types...Identical! > General files... > Jar files... > Libraries... > Binary : Size : Symbols : Deps : Fulldump : Disass : > * diff *: : : :* 126*: : > ./lib/ppc64/libjsig.so > * diff *: : : :* 2745330*:* 9939*: > ./lib/ppc64/server/libjvm.so > > REGRESSIONS FOUND! > > But I think that's OK for now:) > > OK to push? > > Thanks, > Volker From volker.simonis at gmail.com Fri Jun 12 17:58:02 2015 From: volker.simonis at gmail.com (volker.simonis at gmail.com) Date: Fri, 12 Jun 2015 17:58:02 +0000 Subject: hg: build-infra/jdk9/hotspot: New HotSpot build on Linux/ppc64 Message-ID: <201506121758.t5CHw2m6019098@aojmv0008.oracle.com> Changeset: 95bf95781ced Author: simonis Date: 2015-06-12 19:56 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/hotspot/rev/95bf95781ced New HotSpot build on Linux/ppc64 ! makefiles/Common.gmk ! makefiles/GensrcAdlc.gmk ! makefiles/SA.gmk From magnus.ihse.bursie at oracle.com Sat Jun 13 07:01:47 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 13 Jun 2015 09:01:47 +0200 Subject: -static-libgcc vs. -Wl,-Bstatic -lgcc In-Reply-To: References: Message-ID: Volker, Thanks for your analysis. The static/dynamic stdc++ linking is messy, quite possibly even broken in the current implemenation. I have opened a bug for that but can't find it now. The current implemenation in libraries.m4 will replace LDCXX (that is, g++) with LD (that is, gcc) which caused some internal Oracle code to break. Apparently, it works without breaking the build for the open part, but that still looks weird. If we explicitly request to use a toolchain which links with g++, then we shouldn't replace it with gcc just because we're doing static linking. Also, I had not heard about -static-libgcc before (and apparently hadn't Fredrik who wrote the original piece of --with-stdc++lib handling), but it seems like that should be used, for all the platform, yes. Do we even have to use -Wl,-Bstatic -lstdc++ when -static-libgcc is present? If it turns out that this is something we will want to fix in jdk9/dev as well, we typically do either of: A) fixing it directly in jdk9/dev as a separate bug, and then pull it into build-infra after a while when it's propagated into a build, or B) fix it in build-infra, and then pick the relevant parts and put them as a separate bug into jdk9/dev, possibly requiring some merge changes when they get back after a while. B is preferable if it's required urgently in build-infra, or it might need several iterations to get it right. Otherwise A is simpler. /Magnus > 12 jun 2015 kl. 19:50 skrev Volker Simonis : > > Hi, > > while porting the new HS build to linux/ppc64 I saw that we are now setting > some link options unconditionally trough the $(LIBCXX) variable from the > top-level spec.gmk (whihc is good :). With the default configuration, this > variable will contain the value "-Wl,-Bstatic -lstdc++ -lgcc" but this can > be changed by setting --with-stdc++lib=dynamic. Nevertheless, we still set > "-static-libgcc" unconditionally in Common.gmk > > Now there's one think I don't understand (and which isn't related to > ppc64). I thought "-static-libgcc" and "-Wl,-Bstatic -lgcc" should be > equivalent options, but apparently they aren?t. For the new build we use > "-Wl,-Bstatic -lstdc++ -lgcc" and additionally set "-static-libgcc". I > thought it should be possible to remove the "-static-libgcc" setting from > the new HS build system (because the question static/dynamic linking of > libstdc++ should be decided at configure time with the --with-stdc++lib > option. But this will produce a different results. > > Summing it up: > > old build: > -static-libgcc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -ldl -lpthread > > is the same as new build: > -static-libgcc -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread > > but not the same as the new build without "-static-libgcc": > -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread > which dynamically links ibgcc_s.so.1 (at least on x86_64) > > It turns out (if you run gcc with '-v') that with "-static-libgcc" the > command line expands to: > -lgcc -lgcc_eh -lc -lgcc -lgcc_eh > which will all be statically linked. > > while without "-static-libgcc" it expands to: > -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > --no-as-needed > and dynamically links libgcc_s.so.1 (at least on x86_64 but not on ppc64). > > The problem is that "libgcc_s.so.1" is only available as shared library so > we can't statically link it even if we want. > > So should we move "-static-libgcc" to libraries.m4 to the place where we > detect whether to use --with-stdc++lib=static/dynamic because we > apparently can't live without it if we still want to link libgcc statically? > > Regards, > Volker From magnus.ihse.bursie at oracle.com Sat Jun 13 07:11:10 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 13 Jun 2015 09:11:10 +0200 Subject: -static-libgcc vs. -Wl,-Bstatic -lgcc In-Reply-To: References: Message-ID: Also, I think I'm mixing up -static-gcc and -static-stdc++. /Magnus > 13 jun 2015 kl. 09:01 skrev Magnus Ihse Bursie : > > Volker, > > Thanks for your analysis. The static/dynamic stdc++ linking is messy, quite possibly even broken in the current implemenation. I have opened a bug for that but can't find it now. The current implemenation in libraries.m4 will replace LDCXX (that is, g++) with LD (that is, gcc) which caused some internal Oracle code to break. Apparently, it works without breaking the build for the open part, but that still looks weird. If we explicitly request to use a toolchain which links with g++, then we shouldn't replace it with gcc just because we're doing static linking. > > Also, I had not heard about -static-libgcc before (and apparently hadn't Fredrik who wrote the original piece of --with-stdc++lib handling), but it seems like that should be used, for all the platform, yes. > > Do we even have to use -Wl,-Bstatic -lstdc++ when -static-libgcc is present? > > If it turns out that this is something we will want to fix in jdk9/dev as well, we typically do either of: > A) fixing it directly in jdk9/dev as a separate bug, and then pull it into build-infra after a while when it's propagated into a build, or > B) fix it in build-infra, and then pick the relevant parts and put them as a separate bug into jdk9/dev, possibly requiring some merge changes when they get back after a while. > > B is preferable if it's required urgently in build-infra, or it might need several iterations to get it right. Otherwise A is simpler. > > /Magnus > >> 12 jun 2015 kl. 19:50 skrev Volker Simonis : >> >> Hi, >> >> while porting the new HS build to linux/ppc64 I saw that we are now setting >> some link options unconditionally trough the $(LIBCXX) variable from the >> top-level spec.gmk (whihc is good :). With the default configuration, this >> variable will contain the value "-Wl,-Bstatic -lstdc++ -lgcc" but this can >> be changed by setting --with-stdc++lib=dynamic. Nevertheless, we still set >> "-static-libgcc" unconditionally in Common.gmk >> >> Now there's one think I don't understand (and which isn't related to >> ppc64). I thought "-static-libgcc" and "-Wl,-Bstatic -lgcc" should be >> equivalent options, but apparently they aren?t. For the new build we use >> "-Wl,-Bstatic -lstdc++ -lgcc" and additionally set "-static-libgcc". I >> thought it should be possible to remove the "-static-libgcc" setting from >> the new HS build system (because the question static/dynamic linking of >> libstdc++ should be decided at configure time with the --with-stdc++lib >> option. But this will produce a different results. >> >> Summing it up: >> >> old build: >> -static-libgcc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -ldl -lpthread >> >> is the same as new build: >> -static-libgcc -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread >> >> but not the same as the new build without "-static-libgcc": >> -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread >> which dynamically links ibgcc_s.so.1 (at least on x86_64) >> >> It turns out (if you run gcc with '-v') that with "-static-libgcc" the >> command line expands to: >> -lgcc -lgcc_eh -lc -lgcc -lgcc_eh >> which will all be statically linked. >> >> while without "-static-libgcc" it expands to: >> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >> --no-as-needed >> and dynamically links libgcc_s.so.1 (at least on x86_64 but not on ppc64). >> >> The problem is that "libgcc_s.so.1" is only available as shared library so >> we can't statically link it even if we want. >> >> So should we move "-static-libgcc" to libraries.m4 to the place where we >> detect whether to use --with-stdc++lib=static/dynamic because we >> apparently can't live without it if we still want to link libgcc statically? >> >> Regards, >> Volker From volker.simonis at gmail.com Sat Jun 13 14:24:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 13 Jun 2015 16:24:29 +0200 Subject: -static-libgcc vs. -Wl,-Bstatic -lgcc In-Reply-To: References: Message-ID: On 6/13/15, Magnus Ihse Bursie wrote: > Volker, > > Thanks for your analysis. The static/dynamic stdc++ linking is messy, quite > possibly even broken in the current implemenation. I have opened a bug for > that but can't find it now. The current implemenation in libraries.m4 will > replace LDCXX (that is, g++) with LD (that is, gcc) which caused some > internal Oracle code to break. Apparently, it works without breaking the > build for the open part, but that still looks weird. If we explicitly > request to use a toolchain which links with g++, then we shouldn't replace > it with gcc just because we're doing static linking. > > Also, I had not heard about -static-libgcc before (and apparently hadn't > Fredrik who wrote the original piece of --with-stdc++lib handling), but it > seems like that should be used, for all the platform, yes. > > Do we even have to use -Wl,-Bstatic -lstdc++ when -static-libgcc is > present? > I think we don't need -lgcc if -static-libgcc is present. > If it turns out that this is something we will want to fix in jdk9/dev as > well, we typically do either of: > A) fixing it directly in jdk9/dev as a separate bug, and then pull it into > build-infra after a while when it's propagated into a build, or > B) fix it in build-infra, and then pick the relevant parts and put them as a > separate bug into jdk9/dev, possibly requiring some merge changes when they > get back after a while. > > B is preferable if it's required urgently in build-infra, or it might need > several iterations to get it right. Otherwise A is simpler. > I think the change is not urgent but it should be done right:) I think the following questions must be addressed: - do we really need to statically link libgcc (we at SAP and others like RedHat are not doing this since quite some time without problems. - do we really need to statically link libstdc++ (there have been already some good mail threads regarding this topic) - we should ensure that all C++ libraries in the JDK are linked in the same way with regard to libgcc and libstdc++ These discussions should be probably held on the hotspot-dev list. Regards, Volker > /Magnus > >> 12 jun 2015 kl. 19:50 skrev Volker Simonis : >> >> Hi, >> >> while porting the new HS build to linux/ppc64 I saw that we are now >> setting >> some link options unconditionally trough the $(LIBCXX) variable from the >> top-level spec.gmk (whihc is good :). With the default configuration, >> this >> variable will contain the value "-Wl,-Bstatic -lstdc++ -lgcc" but this >> can >> be changed by setting --with-stdc++lib=dynamic. Nevertheless, we still >> set >> "-static-libgcc" unconditionally in Common.gmk >> >> Now there's one think I don't understand (and which isn't related to >> ppc64). I thought "-static-libgcc" and "-Wl,-Bstatic -lgcc" should be >> equivalent options, but apparently they aren?t. For the new build we use >> "-Wl,-Bstatic -lstdc++ -lgcc" and additionally set "-static-libgcc". I >> thought it should be possible to remove the "-static-libgcc" setting from >> the new HS build system (because the question static/dynamic linking of >> libstdc++ should be decided at configure time with the --with-stdc++lib >> option. But this will produce a different results. >> >> Summing it up: >> >> old build: >> -static-libgcc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic -lm -ldl >> -lpthread >> >> is the same as new build: >> -static-libgcc -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl >> -lpthread >> >> but not the same as the new build without "-static-libgcc": >> -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl >> -lpthread >> which dynamically links ibgcc_s.so.1 (at least on x86_64) >> >> It turns out (if you run gcc with '-v') that with "-static-libgcc" the >> command line expands to: >> -lgcc -lgcc_eh -lc -lgcc -lgcc_eh >> which will all be statically linked. >> >> while without "-static-libgcc" it expands to: >> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >> --no-as-needed >> and dynamically links libgcc_s.so.1 (at least on x86_64 but not on >> ppc64). >> >> The problem is that "libgcc_s.so.1" is only available as shared library >> so >> we can't statically link it even if we want. >> >> So should we move "-static-libgcc" to libraries.m4 to the place where we >> detect whether to use --with-stdc++lib=static/dynamic because we >> apparently can't live without it if we still want to link libgcc >> statically? >> >> Regards, >> Volker > From volker.simonis at gmail.com Tue Jun 16 12:42:58 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Jun 2015 14:42:58 +0200 Subject: New HS build: how to handle changes in the top-level repository? Message-ID: Hi, I'm just adapting the new HS build to AIX. The problem is that the AIX xlc compiler uses a different flag for the compiler command file option. While all the currently supported compilers use '@' we have to use '-f' on AIX. In order to fix this, I have to introduce a new variable 'COMPILER_COMMAND_FILE_FLAG' in spek.gmk and set it correspondingly in flags.m4. All this is in the top-level directory so my question is how to handle this as this requires the regeneration of generated-configure.sh which I can only do for the "open part". Is this still important in the build-infra repository (i.e. does build-infra still has a dependency on your 'closed source' configure parts? The other question is how to track dependencies of the new hs build to changes required in the top-level repo. Is this done at all or can I simply push the corresponding hs changes AFTER I pushed the top-level changes? Thank you and best regards, Volker From ingemar.aberg at oracle.com Wed Jun 17 09:38:30 2015 From: ingemar.aberg at oracle.com (ingemar.aberg at oracle.com) Date: Wed, 17 Jun 2015 09:38:30 +0000 Subject: hg: build-infra/jdk9: 2 new changesets Message-ID: <201506170938.t5H9cUub025956@aojmv0008.oracle.com> Changeset: 00e15a85a4f7 Author: iaberg Date: 2015-06-09 07:55 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/rev/00e15a85a4f7 Get new build of SA on arm closer to old build ! common/autoconf/generated-configure.sh Changeset: b2c98158e759 Author: iaberg Date: 2015-06-17 11:38 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk9/rev/b2c98158e759 merge ! common/autoconf/generated-configure.sh From erik.joelsson at oracle.com Wed Jun 17 10:04:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jun 2015 12:04:40 +0200 Subject: New HS build: how to handle changes in the top-level repository? In-Reply-To: References: Message-ID: <55814638.7050108@oracle.com> Hello Volker, Awesome to see you working on this! On 2015-06-16 14:42, Volker Simonis wrote: > Hi, > > I'm just adapting the new HS build to AIX. The problem is that the AIX > xlc compiler uses a different flag for the compiler command file > option. While all the currently supported compilers use '@' > we have to use '-f' on AIX. > > In order to fix this, I have to introduce a new variable > 'COMPILER_COMMAND_FILE_FLAG' in spek.gmk and set it correspondingly in > flags.m4. All this is in the top-level directory so my question is how > to handle this as this requires the regeneration of > generated-configure.sh which I can only do for the "open part". Is > this still important in the build-infra repository (i.e. does > build-infra still has a dependency on your 'closed source' configure > parts? Just push your changes to build-infra. Yes, we will then need to regenerate internally, but it's not a big deal. We will see the push notification emails and fix it as needed, so don't worry about it. Historically in build-infra, we had people forgetting to push the closed regenerated file often enough anyway. > The other question is how to track dependencies of the new hs build to > changes required in the top-level repo. Is this done at all or can I > simply push the corresponding hs changes AFTER I pushed the top-level > changes? We don't explicitly track such dependencies, we just push what we need for now, to any repo in the forest. Just try to not forget to push a repo. :) /Erik > Thank you and best regards, > Volker