Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allowing build from diectory/src snapshot #3724

Closed
wants to merge 4 commits into from

Conversation

judovana
Copy link
Contributor

@judovana judovana commented Mar 22, 2024

#3704

This is initial shot on implementation.

  • It do not support build in container (although I would like to add)
  • cleaning is not perfect (eg build dir in source dir is corrupting it)
  • works above both dirs and tarballs
  • probably missed all possible corener cases

Wdyt?

@judovana judovana changed the title allowing build from diectory allowing build from diectory/src snapshot Mar 22, 2024
@judovana
Copy link
Contributor Author

Note that I intentionally added, and left in some set -x I will remove them once we agree on this.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

@karianna
Copy link
Contributor

@judovana I'm not understanding the use case here. The build scripts already support building from a local directory via the --source <path> flag.

@judovana
Copy link
Contributor Author

judovana commented Mar 24, 2024

The usecase is to build local random dir/local jdk work in progress/local source snaphshot

@judovana I'm not understanding the use case here. The build scripts already support building from a local directory via the --source <path> flag.

Hmm. You understand the scripts hundred times more then me, so you are most likely right.
Before I dived into this, I was advised by @andrew-m-leonard that current scripts do not allow to build random directory or tarred snapshot. I was not trying the --source tbh, as by documentation, I understood it that it will clone the repo to the -s's given location.

Even If I'm wrong (which most likely I'm) the scripts expects git repo (and .git) folder to be present. So that is something I need to get rid to build random dir/source snapshot. That is moreover 100% of this work. I was plying with faking .git repo, in the copy of the random dir/unpacked source snapshot, but that was fragile, and was actually more nasty patch.

Last thing, which is based on previous) the make_any_jdk is fiddling with the repo to much - various reserts, checkouts and so, which moreover prohibits building local copy where is work in progress. But yet again, I'm most likely very wrong and had misunderstood how it should work, or missed set of switches allowing me to build local random dir/local jdk work in progress/local source snaphshot

ps, I had notyiced the shell check issues, most of them are valid, will elaborate as thsi review will progress.

@judovana
Copy link
Contributor Author

judovana commented Mar 25, 2024

The --source is to be dir name/relative path stub. Not even full path:

On current master:
sh makejdk-any-platform.sh --source /tmp/blah jdk11 , where /tmp existed, but /tmp/blah not, had cloned fresh jdk11 to
Could not find a valid openjdk git repository at /home/jvanek/git/temurin-build/workspace/tmp/blah/src so re-cloning the source to openjdk
sh makejdk-any-platform.sh --source /home/jvanek/git/jdk11u-dev/ jdk11 where jdk11u-dev was valid cloned jdk, again make fresh copy Could not find a valid openjdk git repository at /home/jvanek/git/temurin-build/workspace/home/jvanek/git/jdk11u-dev/src so re-cloning the source to openjdk

thus with this change, it behaved correctly:
sh makejdk-any-platform.sh --source /home/jvanek/git/jdk11u-dev/ ~/git/jdk11u-dev/ ->
Copying existing /home/jvanek/git/jdk11u-dev to /home/jvanek/git/temurin-build/workspace/home/jvanek/git/jdk11u-dev/jdk11u-dev to be built

Thanx for pointer! I have most liekly missed much more cases like this...

Actually this exercise showed one more intereresting point.
both sh makejdk-any-platform.sh --source /tmp/blah jdk11 and sh makejdk-any-platform.sh --source /home/jvanek/git/jdk11u-dev/ jdk11 on current master t master: failed compilation very soon, on misaligned gcc/gcc++ versions. However the sh makejdk-any-platform.sh --source /home/jvanek/git/jdk11u-dev/ ~/git/jdk11u-dev/ on this change, passed the build.. Not sure what could be dfferent

@judovana

This comment was marked as outdated.

@andrew-m-leonard
Copy link
Contributor

@judovana i'm afraid I don't quite understand the "use case", can you explain this statement from your issue please?

"It would be nice, if it can - at least in limited scope - work also above local directory with jdk sources or above local tarball >with sources (candy on top of the dir)."

Maybe provide a few examples?

Copy link
Contributor

@andrew-m-leonard andrew-m-leonard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need some example of what this is providing?

@judovana
Copy link
Contributor Author

please any admin, unhide #3724 (comment) ; I do nto have permissions:( It was not supposed ot be hidden

@judovana
Copy link
Contributor Author

judovana commented Mar 25, 2024

And I was hoping to be self describing enough :)

The goal is simple - I have a source tarball or directory, and I want temurin-build to build it for me. No cloning, no playing with tags or branches, ok with no .git dir.

From all I know current scripting do not offer this functionality, and I heavily miss it.

Note that I'm perfectly familiar with jdk build process, and I can turn jdk code-build-test cycles on my own and pretty quickly. This is additional tier - full temurin-close build.
Similarly when somebody sends me a source tarball, I can build i on my own, but I would like temurin-like build to be it.

this is providing the feature: ...some/path/makejdk-any-platform.sh ../someJdkDirOrTarball and temurin-like build will magically appear. In addition temurin build is adding many compliance comfort to the builder.

judovana added a commit to judovana/temurin-build that referenced this pull request Mar 25, 2024
this is partially bound to
adoptium#3724, where dsah and
undersocre are oneof major delimiters in directory names
jdk11u-my_feature

May, or may have not sense without the 3724
judovana added a commit to judovana/temurin-build that referenced this pull request Mar 25, 2024
this is partially bound to
adoptium#3724,
where dash and underscore are one of major delimiters in directory names jdk11u-my_feature

May, or may have not sense without the 3724
@@ -18,6 +18,19 @@
# shellcheck disable=SC2153
function setOpenJdkVersion() {
local forest_name=$1
set -x
if [ -e "${forest_name}" ] ; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the right place for this logic.

  1. Existing build arg --version <forest_name> can be used instead of OPENJDK_FOREST_ALTID
  2. I think specify the openjdk srcDirectory/Tarball via a build arg of say : --openjdk-source <full path to srcDirectory/Tarball> and that sets the variable OPENJDK_FOREST_SOURCE

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two things mixed togehter.

Yyou are absolutly correct and --version is exactly what OPENJDK_FOREST_ALTID was substituing. I will remove --jdk-dir-altid in favour of --version It will need some more changes, nut better then additional single purposed switch. Sorry for missing --version.

I woudl very like to avoid the --openjdk-source. it would kill the script logic. Teh script expects repository_name or dir/tarball. The usage of make_any_jdk.sh dir is much more strigthforward and much usable then the verbose one. In additoon, the script will be pulluted by nasty (imo) if:

"expects exactly one argument, unless --openjdk-source si used, then it expects no argument"

Unless you are expecting the usage as make_any_jdk.sh --openjdk-source some_terrible_name/path/zip id`
Where id is still mandatory, and is providing the necessary "original repo" information.
I like "my" approach a bti more, because it have less mandatory arguments

  • make_any_jdk.sh some_terrible_name/path/zip +optional version id - because the name/path/zip maybe akready proper version.

In comaprison to

  • make_any_jdk.sh --openjdk-source some_terrible_name/path/zip with mandatory --openjdk-source and otional short id.

wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So maybe, the syntax of makejdk-any-platform.sh, is:

makejdk-any-platform.sh <jdk_version>

Where jdk_version is what has historically been named as the "forest version"
From jdk_version you must be able to set:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FOREST_NAME]        eg. jdk21u
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER] eg. 21

These are needed throughtout the sbin/build.sh build logic.. So you will need to set these from some_terrible_name/path/zip ??

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would actually prefer:

makejdk-any-platform.sh jdk21u --openjdk-source some_terrible_name/path/zip

because the existing logic very clearly set:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]   eg. 21

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So maybe, the syntax of makejdk-any-platform.sh, is:

makejdk-any-platform.sh <jdk_version>

Where jdk_version is what has historically been named as the "forest version" From jdk_version you must be able to set:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FOREST_NAME]        eg. jdk21u
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER] eg. 21

These are needed throughtout the sbin/build.sh build logic.. So you will need to set these from some_terrible_name/path/zip ??

Exactly, And thats what that dir/zip i susually named. See #3727
For cases Where the the dir/tarball is nonsense from this pint of vie, I introduced that altid, which will be substituted by version. And used that to set featureversion, if used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would actually prefer:

makejdk-any-platform.sh jdk21u --openjdk-source some_terrible_name/path/zip

because the existing logic very clearly set:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]   eg. 21

Probably my main reason is to save typing --openjdk-source every time I wish to build some properly named directory:( I was resuing the logic which set

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]   eg. 21

properly. Do you really insists?

if [ -e "${forest_name}" ] ; then
BUILD_CONFIG[OPENJDK_FOREST_DIR]="true"
BUILD_CONFIG[OPENJDK_FOREST_DIR_ABSPATH]=$(readlink -f "${forest_name}")
BUILD_CONFIG[DISABLE_ADOPT_BRANCH_SAFETY]="true"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User should specify build arg: --disable-adopt-branch-safety

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was breaking in the branching block. I can remove this, but conisder:

  • the branch safety is usels above tarball/dir without .git
  • I will need to add if into the block using BUILD_CONFIG[DISABLE_ADOPT_BRANCH_SAFETY]

I will obey as you need, but the setup of it sounds to me more clean and less harmfull.

# we want to use "." and similar
forest_name=$(basename "${BUILD_CONFIG[OPENJDK_FOREST_DIR_ABSPATH]}")
fi
BUILD_CONFIG[OPENJDK_SOURCE_DIR]="${forest_name}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't set OPENJDK_SOURCE_DIR, as that is set to the folder under the WORK_DIR, default "src", and is where the git clone of openjdk clones the source.
The unzipping/copying of the forest source, should unzip/copy to the OPENJDK_SOURCE_DIR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah, I agree, I think I set it because I was unsure how to proeprly set the name to be read by. Will elaborate and fix

@@ -82,7 +82,10 @@ NUM_PROCESSORS
OPENJDK_BUILD_NUMBER
OPENJDK_CORE_VERSION
OPENJDK_FEATURE_NUMBER
OPENJDK_FOREST_ALTID
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all you need is a OPENJDK_FOREST_SOURCE build arg

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean --version ? Thats what I will use instead of OPENJDK_FOREST_ALTID. The directory/tarball should remain the only mandatory argument, which was name of the repo untill now.

@@ -24,7 +24,7 @@
################################################################################

set -eu

set -x
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove debug..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure thing. before merge, all -x will be removed. I think there is still quite some iterations ahead. of us. Thanx a lot fo reding it through!

@@ -37,14 +37,52 @@ ALSA_LIB_CHECKSUM=${ALSA_LIB_CHECKSUM:-5f2cd274b272cae0d0d111e8a9e363f0878332915
ALSA_LIB_GPGKEYID=${ALSA_LIB_GPGKEYID:-A6E59C91}
FREETYPE_FONT_SHARED_OBJECT_FILENAME="libfreetype.so*"


copyFromDir() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copyFromDir() and unpackFromArchive() need to "copy"/"unpack" the forest openjdk source to where the build scripts intends to build the source within the defined WORKING_DIR,
ie. both these methods need to end up copying the source to be built to the location:

"${BUILD_CONFIG[WORKSPACE_DIR]:?}/${BUILD_CONFIG[WORKING_DIR]}/${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original clonnign script is using the "." too, if that is what you are reffereing. I was wondering too that there is no ful apth, but just "."

I will heapily switch to full path instead of "." but allt he cloning methods were really exppecting other parts to cd for them. Can you confirm please?

echo "Not directory nor file ${BUILD_CONFIG[OPENJDK_FOREST_DIR_ABSPATH]}"
exit 1
fi
rm -vf ./${BUILD_CONFIG[OPENJDK_FOREST_NAME]}/build/*/configure-support/config.status
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be needed as the build-scripts will clean the autoconf configuration in the intended build location.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unluckily it is necessary. The methods later in build.sh, are not expoecting prexsiting configuration, and the builds were failing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you copyOrUntarZip() methods should be copying/untaring the source to where temurin-build scripts is doing the build, ie. to ${BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}
So you can simply exclude copying "build/*"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Thats what they do (the copying is on correect place, to correct destination, simply substituting instea of the cloned repo.
  • I will try to exclude build. Will be indeed better.

# Create a new clone or update the existing clone of the OpenJDK source repo
# TODO refactor this for Single Responsibility Principle (SRP)
checkoutAndCloneOpenJDKGitRepo() {

cd "${BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}"

# Check that we have a git repo, we assume that it is a repo that contains openjdk source
if [ -d "${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}/.git" ]; then
if [ -d "${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}/.git" -a "${BUILD_CONFIG[OPENJDK_FOREST_DIR]}" == "false" ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use && to be consistent with this script

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ouch. Sorry. Will do!


if [ -d "${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}/.git" ]; then
if [ "${BUILD_CONFIG[OPENJDK_FOREST_DIR]}" == "true" ]; then
echo "Version: local dir; OPENJDK_BUILD_NUMBER set as ${BUILD_CONFIG[OPENJDK_BUILD_NUMBER]}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OPENJDK_BUILD_NUMBER is in fact just the openjdk build number, so for example jdk-21.0.2+13, the build number is just "13"
I think you probably want to use "TAG" in this echo statement, and when you build from your own forest source you would pass arguments:

--openjdk-source <path_to_tarball>
--tag jdk-17.0.12+4

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. Surprisingly in this whole enhancement I was not calculating with the tag. It is jsut tarball/dir - I do pretend I do not care baout whatever version it is/was. However jdk major "the number" is absolutely necessary, is deducted few times, by various ways, and there is no way around.

I will keep this as it is, unless the tags will come more to play.

local openj9_openjdk_tag_file="${BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/${BUILD_CONFIG[OPENJDK_SOURCE_DIR]}/closed/openjdk-tag.gmk"
if [[ "${BUILD_CONFIG[BUILD_VARIANT]}" == "${BUILD_VARIANT_OPENJ9}" ]] && [[ -f "${openj9_openjdk_tag_file}" ]]; then
firstMatchingNameFromRepo=$(grep OPENJDK_TAG ${openj9_openjdk_tag_file} | awk 'BEGIN {FS = "[ :=]+"} {print $2}')
if [ "${BUILD_CONFIG[OPENJDK_FOREST_DIR]}" == "true" ]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't modify the getFirstTagFromOpenJDKGitRepo() method at all, it should only be called for a "git repo",
instead you need to modify the getOpenJdkVersion() to correctly return the jdk tag version of the forest openjdk source, I suspect as specified via the build arg --tag <jdk tag version>.
So I am thinking if --openjdk-source <path to tarball> is specified then --tag <jdk tag version> is mandatory in order to specify what the version within the source tarball is being built...
The tag version string is used by the build scripts for things like the image archive filenames...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't modify the getFirstTagFromOpenJDKGitRepo() method at all, it should only be called for a "git repo", instead you need to modify the getOpenJdkVersion() to correctly return the jdk tag version of the forest openjdk

Thanx, will do!

source, I suspect as specified via the build arg --tag . So I am thinking if --openjdk-source is specified then --tag is mandatory in order to specify what the version within the source tarball is being built... The tag version string is used by the build scripts for things like the image archive filenames...

I think it defaults to some unknonw or head, but I will double check. If it do not default, then I would rather default it to some "local" rather then make it mandatory. Of course, it it is set, then it will be used

@andrew-m-leonard
Copy link
Contributor

andrew-m-leonard commented Mar 25, 2024

@judovana
Hi Jiri,
I've added a number of comments and suggestions, I understand I think what you're after, and I think we can simplify it a bit.
My thoughts:

  1. I think we can get away with only adding one new build arg:
--openjdk-source <path to openjdk src directory or tarball>
  1. When --openjdk-source is specified it sets OPENJDK_FOREST_SOURCE to that path, and also mandates the use of --tag <jdk tag version>
  2. Then in the build scripts build.sh, the logic that currently checks out the required git code to the area where the build-scripts want to build, which is BUILD_CONFIG[WORKSPACE_DIR]}/BUILD_CONFIG[WORKING_DIR]/BUILD_CONFIG[OPENJDK_SOURCE_DIR], will instead "copy" or "unzip" the OPENJDK_FOREST_SOURCE into that location, ie.logically:
unzip OPENJDK_FOREST_SOURCE into $BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/${BUILD_CONFIG[OPENJDK_SOURCE_DIR]
  1. If the source is not an Adoptium mirror, then you will need to use the existing build arg:
--disable-adopt-branch-safety

Ping me if you have any questions

@judovana
Copy link
Contributor Author

@judovana Hi Jiri, I've added a number of comments and suggestions, I understand I think what you're after, and I think we can simplify it a bit. My thoughts:

1. I think we can get away with only adding one new build arg:
--openjdk-source <path to openjdk src directory or tarball>

Please dont, I would liek to go without any switch at all. The altid was optional safety belt, and will be removed, in favour of version (with adjsuted man page).

The <path to openjdk src directory or tarball> should remain the solemn mandatory arg.

2. When --openjdk-source is specified it sets OPENJDK_FOREST_SOURCE to that path, and also mandates the use of --tag <jdk tag version>

I sitll hesitate on this. If tag would be specifed, then sure, it must be used. But without it, I would jsut default to "local" or similarly., rather then doing it mandatory.

3. Then in the build scripts build.sh, the logic that currently checks out the required git code to the area where the build-scripts want to build, which is BUILD_CONFIG[WORKSPACE_DIR]}/BUILD_CONFIG[WORKING_DIR]/BUILD_CONFIG[OPENJDK_SOURCE_DIR], will instead "copy" or "unzip" the OPENJDK_FOREST_SOURCE into that location, ie.logically:
unzip OPENJDK_FOREST_SOURCE into $BUILD_CONFIG[WORKSPACE_DIR]}/${BUILD_CONFIG[WORKING_DIR]}/${BUILD_CONFIG[OPENJDK_SOURCE_DIR]

Fair enough. As I described earlier, the git operations expect proepr cwd, adn are using "." . I was jsut keeping consitent with it. I can of course (and galdlY!) use what you suggests, but it will diverg from clones. Ok?

4. If the source is not an Adoptium mirror, then you will need to use the existing build arg:
--disable-adopt-branch-safety

As this is removing any forms of .git (unlessby error packed in source snapshot) I set it in the if block - BUILD_CONFIG[DISABLE_ADOPT_BRANCH_SAFETY]="true"

I would liek to keep ti as it is. As this work is avoidign any git at all!

Ping me if you have any questions

done!

Tyvm for review !

@andrew-m-leonard
Copy link
Contributor

andrew-m-leonard commented Mar 25, 2024

You need to ensure whatever argument is specified, that you can determine:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]   eg. 21

from them, as these must be set correctly so that the build scripts know what version specific stuff they need to do...

With you forest source selection, no "git" operations should occur on the BUILD_CONFIG[WORKSPACE_DIR]/BUILD_CONFIG[WORKING_DIR]/BUILD_CONFIG[OPENJDK_SOURCE_DIR]

@judovana
Copy link
Contributor Author

judovana commented Mar 25, 2024

You need to ensure whatever argument is specified, that you can determine:

BUILD_CONFIG[OPENJDK_CORE_VERSION]       eg. jdk21
BUILD_CONFIG[OPENJDK_FEATURE_NUMBER]   eg. 21

from them, as these must be set correctly so that the build scripts know what version specific stuff they need to do...

I know. Tahts what ALTID was for. And now --version eill be used as you advised.

With you forest source selection, no "git" operations should occur on the BUILD_CONFIG[WORKSPACE_DIR]/BUILD_CONFIG[WORKING_DIR]/BUILD_CONFIG[OPENJDK_SOURCE_DIR]

Sure, will do. Still I'm wondering if it is not agasint he tide of "." of git clone. But sure!

@judovana
Copy link
Contributor Author

judovana commented Mar 26, 2024

Just to confirm. Currently there are two proposed solutions of usecase:
make_any_platform.sh --version ifDirIsNotParseable DIR_OR_REPO
or
make_any_platformsh --openjdk-sources alwaysNeeded REPO

From those two I prefere first one, as it is less verbose. On contrary, it is giving the dir_or_repo dual meaning.
Second one will is quite unnecessary verbose, but is a bit more understandable.

@judovana
Copy link
Contributor Author

Just to confirm. Currently there are two proposed solutions of usecase: make_any_platform.sh --version ifDirIsNotParseable DIR_OR_REPO or make_any_platformsh --openjdk-sources alwaysNeeded REPO

From those two I prefere first one, as it is less verbose. On contrary, it is giving the dir_or_repo dual meaning. Second one will is quite unnecessary verbose, but is a bit more understandable.

We had small chat with @andrew-m-leonard and we decided that thsi feature can go in, once I rework it for make_any_platformsh --openjdk-sources alwaysNeeded REPO

As this will need major rework of the patch, I will close this PR and open new one

@judovana
Copy link
Contributor Author

surpassed by #3737

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants