You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Stefan Bodewig <bo...@apache.org> on 2017/05/06 11:28:44 UTC
build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
On 2017-05-06, Shad Storhaug wrote:
> Stefan,
>> The build.bat inside the source zip is different from the one inside the tag, is this intentional?
> Yes, build.bat is generated by the build script in the "Lucene.Net
> Release" build configuration on TeamCity.
I see, thank you.
> In the future, I believe we could add a launch script that runs
> cross-platform so you can just type "build" from the CLI, but I
> haven't worked with such scripts nor do I currently have access to
> other platforms to test it with.
I happen to work almost exclusively on Linux and may be able to lend a
hand.
> For the time being, you would need to execute the following command on
> Mac/Linux (untested):
> powershell -ExecutionPolicy Bypass -Command "& { Import-Module /build/psake.psm1; Invoke-Psake /build/build.ps1 -properties @{prepareForBuild='false';backup_files='false'} }"
results in
Import-Module : The specified module '/build/psake.psm1' was not loaded
because no valid module file was found in any module directory.
and errors that stem from this. Removing the leading slash doesn't
change anything. I don't know enough about powrshell (much less so on
Linux) to see what's wrong right now, but am more than willing to be the
guinea pig.
Stefan
Re: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2017-05-06, Shad Storhaug wrote:
> Ahh, that was something I didn't realize. Psake has been around longer than cross-platform support in Powershell - and I guess since it is not being maintained anymore, cross-platform support is not yet in its feature set.
> It looks like someone has made a pull request to skip over the framework scan when not on Windows, though: https://github.com/psake/psake/pull/198. I believe that would do the trick to get it running.
Yes, I have seen that PR which seems to do a few mor things (expanding
aliases with full cmdlet names). I can experiment a little with that
when I find time and will do so on a branch as I'll probably lack the
Windows system to test the impact of my changes with.
Stefan
RE: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Ahh, that was something I didn't realize. Psake has been around longer than cross-platform support in Powershell - and I guess since it is not being maintained anymore, cross-platform support is not yet in its feature set.
It looks like someone has made a pull request to skip over the framework scan when not on Windows, though: https://github.com/psake/psake/pull/198. I believe that would do the trick to get it running.
-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Saturday, May 6, 2017 10:50 PM
To: dev@lucenenet.apache.org
Subject: Re: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
On 2017-05-06, Stefan Bodewig wrote:
> If the build requires .NET 4.x them I out of luck. .NET Core and Mono
> 4.x are installed. I'll try to free up some cycles to debug this myself.
ConfigureBuildEnvironment in psake.psm1 looks as if it really wanted a full .NET Framework and really wanted Windows.
This is not a high priority right now.
Stefan
Re: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2017-05-06, Stefan Bodewig wrote:
> If the build requires .NET 4.x them I out of luck. .NET Core and Mono
> 4.x are installed. I'll try to free up some cycles to debug this myself.
ConfigureBuildEnvironment in psake.psm1 looks as if it really wanted a
full .NET Framework and really wanted Windows.
This is not a high priority right now.
Stefan
Re: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2017-05-06, Shad Storhaug wrote:
> I figured as much. In Windows, the command looks like:
> powershell -ExecutionPolicy Bypass -Command "& { Import-Module .\build\psake.psm1; Invoke-Psake .\build\build.ps1 -properties @{prepareForBuild='false';backup_files='false'} }"
> where the '.' indicates the current directory. I wasn't sure how to
> specify the current directory on Linux/Mac - is it a '.' as well?
Yes. I could have tried that myself.
Error: 06.05.17 17:36:23:
At /devel/ASF/lucenenet/build/psake.psm1:193 char:9 + throw ("Assert: " + $failureMessage) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Assert: No .NET Framework installation directory found at \Microsoft.NET\Framework64\v4.0.30319\.
If the build requires .NET 4.x them I out of luck. .NET Core and Mono
4.x are installed. I'll try to free up some cycles to debug this myself.
> I know the slashes go the other way, though, and I am pretty sure that both dotnet.exe and powershell.exe run on Linux.
They do. I've got .NET Core (still 1.1 with project.json instead of XML
project files) and Powershell installed.
> As for the "build" command, I have seen other projects double down by putting both a "build.bat" (or "build.cmd") and "build.sh" launcher files into their build system (have a look at https://github.com/dotnet/corefx).
I can easily add a build.sh that does the same as your .bat - I can also
try to figure out the powershell stuff on my machine myself. I don't
expect to be the first one trying to run Powershell on .NET Core on
Linux.
Stefan
RE: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
Stefan,
> > powershell -ExecutionPolicy Bypass -Command "& { Import-Module /build/psake.psm1; Invoke-Psake /build/build.ps1 -properties @{prepareForBuild='false';backup_files='false'} }"
> results in
> Import-Module : The specified module '/build/psake.psm1' was not loaded because no valid module file was found in any module directory.
> and errors that stem from this. Removing the leading slash doesn't change anything. I don't know enough about powrshell (much less so on
> Linux) to see what's wrong right now, but am more than willing to be the guinea pig.
I figured as much. In Windows, the command looks like:
powershell -ExecutionPolicy Bypass -Command "& { Import-Module .\build\psake.psm1; Invoke-Psake .\build\build.ps1 -properties @{prepareForBuild='false';backup_files='false'} }"
where the '.' indicates the current directory. I wasn't sure how to specify the current directory on Linux/Mac - is it a '.' as well? I know the slashes go the other way, though, and I am pretty sure that both dotnet.exe and powershell.exe run on Linux.
As for the "build" command, I have seen other projects double down by putting both a "build.bat" (or "build.cmd") and "build.sh" launcher files into their build system (have a look at https://github.com/dotnet/corefx).
Thanks,
Shad Storhaug (NightOwl888)
-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Saturday, May 6, 2017 6:29 PM
To: dev@lucenenet.apache.org
Subject: build script (was Re: [Vote] Apache Lucene.Net 4.8.0-beta00001)
On 2017-05-06, Shad Storhaug wrote:
> Stefan,
>> The build.bat inside the source zip is different from the one inside the tag, is this intentional?
> Yes, build.bat is generated by the build script in the "Lucene.Net
> Release" build configuration on TeamCity.
I see, thank you.
> In the future, I believe we could add a launch script that runs
> cross-platform so you can just type "build" from the CLI, but I
> haven't worked with such scripts nor do I currently have access to
> other platforms to test it with.
I happen to work almost exclusively on Linux and may be able to lend a hand.
> For the time being, you would need to execute the following command on
> Mac/Linux (untested):
> powershell -ExecutionPolicy Bypass -Command "& { Import-Module /build/psake.psm1; Invoke-Psake /build/build.ps1 -properties @{prepareForBuild='false';backup_files='false'} }"
results in
Import-Module : The specified module '/build/psake.psm1' was not loaded because no valid module file was found in any module directory.
and errors that stem from this. Removing the leading slash doesn't change anything. I don't know enough about powrshell (much less so on
Linux) to see what's wrong right now, but am more than willing to be the guinea pig.
Stefan