Created attachment 872100 [details] example of possible change Please add the --verbosity flag with which option seems suitable to match the rest of the gentoo emerge system (ie most ninja builds use -v) to the new dotnet-sdk ebuild, attached below is an possible example of where this could be added to improve the out of the sdk build to make debugging easier, thanks for making this ebuild as well!
--verbosity can be either normal,detailed,etc shorthand is q,n,d,dd (mainly for debug is dd)
>=8.0.0 does not seem to have this switch available. Also, what we **should** have is to output all the stuff that goes into logs on the STDOUT of build script. Unfortunately I have no idea if that's possible. And i do not think tweaking verbosity settings of the build scripts does **that**.
(In reply to Maciej Barć from comment #2) > >=8.0.0 does not seem to have this switch available. > > Also, what we **should** have is to output all the stuff that goes into logs > on the STDOUT of build script. Unfortunately I have no idea if that's > possible. > And i do not think tweaking verbosity settings of the build scripts does > **that**. Yes true, still would wish the verbosity switch would be added to the build.sh script just to make the build of the package more verbose, will look into how to generate a log output thanks Maciej
Obtaining build logs with msbuild by microsoft (cant post urls) could be of intrest as ./build.sh pipes --options into msbuild I believe could use this to make a log?
(In reply to Kyle Rabago from comment #4) > Obtaining build logs with msbuild by microsoft (cant post urls) could be of > intrest as ./build.sh pipes --options into msbuild I believe could use this > to make a log? Maybe. This needs more investigation but if we could nail down how the build script/msbuild outputs to logs then maybe we can hack our way with using "tee"... maybe. :P
(In reply to Maciej Barć from comment #5) > (In reply to Kyle Rabago from comment #4) > > Obtaining build logs with msbuild by microsoft (cant post urls) could be of > > intrest as ./build.sh pipes --options into msbuild I believe could use this > > to make a log? > > Maybe. This needs more investigation but if we could nail down how the build > script/msbuild outputs to logs then maybe we can hack our way with using > "tee"... maybe. :P We can use -flp:logfile=logfile.log;verbosity=diagnostic,normal,detailed to do this! and we can specify the location of the logfile via =/usr/etc for example, we can then also put --verbose infront of this to make it print out the build and ALSO write to a build log of our chosing in name and location
(In reply to Kyle Rabago from comment #6) > (In reply to Maciej Barć from comment #5) > > (In reply to Kyle Rabago from comment #4) > > > Obtaining build logs with msbuild by microsoft (cant post urls) could be of > > > intrest as ./build.sh pipes --options into msbuild I believe could use this > > > to make a log? > > > > Maybe. This needs more investigation but if we could nail down how the build > > script/msbuild outputs to logs then maybe we can hack our way with using > > "tee"... maybe. :P > > We can use -flp:logfile=logfile.log;verbosity=diagnostic,normal,detailed to > do this! and we can specify the location of the logfile via =/usr/etc for > example, we can then also put --verbose infront of this to make it print out > the build and ALSO write to a build log of our chosing in name and location Are you looking at 7.0 or 8.0 sources? Can you make a patch?
(In reply to Maciej Barć from comment #7) > (In reply to Kyle Rabago from comment #6) > > (In reply to Maciej Barć from comment #5) > > > (In reply to Kyle Rabago from comment #4) > > > > Obtaining build logs with msbuild by microsoft (cant post urls) could be of > > > > intrest as ./build.sh pipes --options into msbuild I believe could use this > > > > to make a log? > > > > > > Maybe. This needs more investigation but if we could nail down how the build > > > script/msbuild outputs to logs then maybe we can hack our way with using > > > "tee"... maybe. :P > > > > We can use -flp:logfile=logfile.log;verbosity=diagnostic,normal,detailed to > > do this! and we can specify the location of the logfile via =/usr/etc for > > example, we can then also put --verbose infront of this to make it print out > > the build and ALSO write to a build log of our chosing in name and location > > Are you looking at 7.0 or 8.0 sources? > Can you make a patch? I am using the git clone of the sdk, i can try this with the sources right now to see if this still works!
(In reply to Kyle Rabago from comment #8) > I am using the git clone of the sdk, i can try this with the sources right > now to see if this still works! Since the build strategy changed between 7 and 8, work against the >=8.0.0 then please.
(In reply to Maciej Barć from comment #9) > (In reply to Kyle Rabago from comment #8) > > I am using the git clone of the sdk, i can try this with the sources right > > now to see if this still works! > > Since the build strategy changed between 7 and 8, work against the >=8.0.0 > then please. Ill do it with 8 then 7 give me a minute to test this real quick
(In reply to Maciej Barć from comment #9) > (In reply to Kyle Rabago from comment #8) > > I am using the git clone of the sdk, i can try this with the sources right > > now to see if this still works! > > Since the build strategy changed between 7 and 8, work against the >=8.0.0 > then please. if this is the case, it really shouldnt matter as both use msbuild correct to build?
(In reply to Maciej Barć from comment #9) > (In reply to Kyle Rabago from comment #8) > > I am using the git clone of the sdk, i can try this with the sources right > > now to see if this still works! > > Since the build strategy changed between 7 and 8, work against the >=8.0.0 > then please. After looking at the tarball, we could pass the necessary msbuild arguments as stated in the build.sh -h via using "-- -flp:logfile=MyProjectOutput.log;verbosity=diagnostic"
I am trying to pass the verbosity flag to the build.sh however for someone reason the msbuild doesnt recognize it because it says its not a valid verbosity level
(In reply to Kyle Rabago from comment #13) > I am trying to pass the verbosity flag to the build.sh however for someone > reason the msbuild doesnt recognize it because it says its not a valid > verbosity level Wow I cant belive I did not realize this earlier, in order to do this and not only print verbosly to the output and LOG the build, we must edit the .proj files as the way that all of the projects are built is determined by Directory.Build.Targets file and in this file we can pass arguments to msbuild that will make it not only print verbosley but also log. Doing some testing right now with 8.0 will let you know
So after much looking into .proj and other files, it seems the main way we will do this is via patching the directory.build.targets file to specify the verbosity manually and not let it print to a log, we can then use the --flp option to create our own log and print verbosely for each project as its built, this is for version 8.0 and if we do this it means the build will not auto log but instead print verbosely and also log into our own log that we can specify with the -flp option, please let me know what you think of this or if there is maybe another simpler method that could involve the exporting of the vars that would have to be removed from the targets file, the flp option however is the only way we can create our own log for the package being build
(In reply to Kyle Rabago from comment #15) > So after much looking into .proj and other files, it seems the main way we > will do this is via patching the directory.build.targets file to specify the > verbosity manually and not let it print to a log, we can then use the --flp > option to create our own log and print verbosely for each project as its > built, this is for version 8.0 and if we do this it means the build will not > auto log but instead print verbosely and also log into our own log that we > can specify with the -flp option, please let me know what you think of this > or if there is maybe another simpler method that could involve the exporting > of the vars that would have to be removed from the targets file, the flp > option however is the only way we can create our own log for the package > being build I would like to see a diff between new and old version of directory.build.targets. I do not think variables in directory.build.targets can be specified in env vars :/
(In reply to Maciej Barć from comment #16) > (In reply to Kyle Rabago from comment #15) > > So after much looking into .proj and other files, it seems the main way we > > will do this is via patching the directory.build.targets file to specify the > > verbosity manually and not let it print to a log, we can then use the --flp > > option to create our own log and print verbosely for each project as its > > built, this is for version 8.0 and if we do this it means the build will not > > auto log but instead print verbosely and also log into our own log that we > > can specify with the -flp option, please let me know what you think of this > > or if there is maybe another simpler method that could involve the exporting > > of the vars that would have to be removed from the targets file, the flp > > option however is the only way we can create our own log for the package > > being build > > I would like to see a diff between new and old version of > directory.build.targets. > > I do not think variables in directory.build.targets can be specified in env > vars :/ thats my next step is to create a patch file for you to look at
Created attachment 872106 [details, diff] Patch for directory.build.targets This is the possible patch to fix the output
And this is what I am passing to build.sh in order for it to log the build -- "-flp:logfile=MyProjectOutput.log;verbosity=diagnostic"
After looking more into it, it is most likely nessesary to patch out and fix the verbosity for each one of the projs
(In reply to Kyle Rabago from comment #20) > After looking more into it, it is most likely nessesary to patch out and fix > the verbosity for each one of the projs This is false, each proj has a LogVerbosityOptout and if its set to false it fixes the issues for each one, now going to try and fix this for all proj files and will report back
(In reply to Kyle Rabago from comment #21) > (In reply to Kyle Rabago from comment #20) > > After looking more into it, it is most likely nessesary to patch out and fix > > the verbosity for each one of the projs > > This is false, each proj has a LogVerbosityOptout and if its set to false it > fixes the issues for each one, now going to try and fix this for all proj > files and will report back Only certain ones seem to have this, so we will need to patch each one that does have this and ignore the ones that dont as well as the overall directory.build.targets
At this point I am pretty much gonna leave it to the devs such as yourself, since this entire package is incredibly confusing as much of the proj and target files all have variables they depend on and stuff and its becoming a mess to get this thing to build verbosely or even log to the output, the only way we could do this I see is to patch each .proj file and stuff and I dont know enough about bash to make this possible and also how to edit the env vars or where these vars are even set at
(In reply to Kyle Rabago from comment #23) > At this point I am pretty much gonna leave it to the devs such as yourself, > since this entire package is incredibly confusing as much of the proj and > target files all have variables they depend on and stuff and its becoming a > mess to get this thing to build verbosely or even log to the output, the > only way we could do this I see is to patch each .proj file and stuff and I > dont know enough about bash to make this possible and also how to edit the > env vars or where these vars are even set at however as it stands the best solution i have came up with is to patch out all the necessary .proj files and the target file to make it so that each individual project that is in the tarball is build verbosely and prints to a log of our own creation, however still need the runtime nugets to build as well of which i dont have on my machine (not running gentoo natively, will try in vm) so yeah let me know what you think of this
(In reply to Kyle Rabago from comment #24) > (In reply to Kyle Rabago from comment #23) > > At this point I am pretty much gonna leave it to the devs such as yourself, > > since this entire package is incredibly confusing as much of the proj and > > target files all have variables they depend on and stuff and its becoming a > > mess to get this thing to build verbosely or even log to the output, the > > only way we could do this I see is to patch each .proj file and stuff and I > > dont know enough about bash to make this possible and also how to edit the > > env vars or where these vars are even set at > > however as it stands the best solution i have came up with is to patch out > all the necessary .proj files and the target file to make it so that each > individual project that is in the tarball is build verbosely and prints to a > log of our own creation, however still need the runtime nugets to build as > well of which i dont have on my machine (not running gentoo natively, will > try in vm) so yeah let me know what you think of this And now that I am testing it again it turns out that the target file is all we need to edit as if we set the true to false on the line that is edited in the patch, it automatically fixes anything that would be in the proj files the only other things that dont print nessarly verbosely is the nupkgs as they are built
(In reply to Kyle Rabago from comment #25) > (In reply to Kyle Rabago from comment #24) > > (In reply to Kyle Rabago from comment #23) > > > At this point I am pretty much gonna leave it to the devs such as yourself, > > > since this entire package is incredibly confusing as much of the proj and > > > target files all have variables they depend on and stuff and its becoming a > > > mess to get this thing to build verbosely or even log to the output, the > > > only way we could do this I see is to patch each .proj file and stuff and I > > > dont know enough about bash to make this possible and also how to edit the > > > env vars or where these vars are even set at > > > > however as it stands the best solution i have came up with is to patch out > > all the necessary .proj files and the target file to make it so that each > > individual project that is in the tarball is build verbosely and prints to a > > log of our own creation, however still need the runtime nugets to build as > > well of which i dont have on my machine (not running gentoo natively, will > > try in vm) so yeah let me know what you think of this > > And now that I am testing it again it turns out that the target file is all > we need to edit as if we set the true to false on the line that is edited in > the patch, it automatically fixes anything that would be in the proj files > the only other things that dont print nessarly verbosely is the nupkgs as > they are built Am building right now to check stuff, will submit a sorta patch file when finished with all changes needed to make the build work verbose wise
Esentially the targets file found in repo-projects needs to be changed as shown in my new patch however each individual .proj file needs to be looked at in terms of the loggingverbosityoptodd true/false thing in order for the correct /v:n or -v n to be applied in terms of each project, ie rosyln.proj needs false, fsharp needs true, etc however most can use the true flag however some cant as -v is not recognized in the build for that project, I am gonna leave it there for you Maciej for you to see whether or not you want to then add -flp to the inital build.sh or change the v:n to a more verbose v:d/-v d etc Thanks again for the ebuild in the first place
Created attachment 872112 [details, diff] Final Verbose Patch for target file Hopefully this helps in terms of getting this ebuild more verbose and inline with rest of gentoo overall
Once again thanks and I hope you can get to the bottom of this I cant wait to see where this goes!
