Thu 22 May 2008 08:28:20 PM UTC, comment #3:
> Do you have a reproducible test case ?
I can reproduce the problem with one framework and three applications (aggregate project with plugins) from the Etoile tree on FreeBSD. I don't know if I can reproduce the issue on Linux though. Some subtle interaction with sudo may be involved because sudo version on FreeBSD 7 comes with the flag -E. My Ubuntu install comes with an older version where this flag isn't needed to preserve the environment. However the latest Ubuntu release (Hardy Heron) comes with an updated sudo versions that needs the -E flag. There is a mail from Rubens_Septimus on gnustep-discuss<http://lists.gnu.org/archive/html/discuss-gnustep/2008-05/msg00090.html> where he detailed the same sort of error on that latest Ubuntu release. Not sure it's the same though (could be caused by root owned files) but I thought it was worth to mention.
Thanks for the explanation about make vs make && make install, I wasn't aware of that and I would suggest to add a note in gnustep-make documentation. Usually I always type 'make && sudo make install' since typing only 'sudo make install' create root owned files in my working copy and force me to later type 'sudo make' for a simple compilation.
As you suggested in your first post, I ran gmake distclean in the projects I have trouble with (without warnings about files owned by root). Then I rebuilt each project like that :
gmake
sudo -E gmake install
By doing that, I got the same issues I reported.
So I put in attachment the logs for gmake and gmake install for a framework and an application where sudo -E gmake install still fail:
- http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/IconKit
- http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/Private/MenuServer/
Before running these commands, I built the whole Etoile tree by typing :
- gmake in http://svn.gna.org/viewcvs/etoile/trunk/Etoile/ for satisfying the dependencies of the two projects (the dependencies are exported in an Etoile/Build directory created by etoile.make which is included by the main GNUmakefile of each project in the source tree)
You can find etoile.make here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/etoile.make
then I cleaned the projects for which I was going to collect the logs:
- gmake distclean in IconKit and MenuServer directory
My revision of Etoile tree is 3107, no changes have been done since then to either IconKit, MenuServer or etoile.make.
What you describe in your last post reminds me that I have observed such spurious rebuilds of some frameworks when typing: sudo make install. However I don't have the issue presently on FreeBSD unlike on my Ubuntu install. In the past, I have also observed that these issues (spurious rebuild, plmerge not found) were also varying with the level in the source tree where you run make. For example, running 'make' in etoile/Etoile/Frameworks would succeed when it would fail if you run in the parent directory etoile/Etoile/. I haven't tested for a while whether that still holds. It's quite possible this problem has been solved by past year gnustep-make releases.
>> the following line fails by trying to run plmerge:
>> sudo -E gmake messages=yes install
>> when the following line succeeds (plmerge isn't run):
>> sudo -E gmake install messages=yes
>
>
as far as I know the two commands are completely identical.
>
> Did you try them in sequence ? Then maybe the first one
> failed because it detected that a rebuilt was needed,
> did the rebuilt and failed trying to run plmerge
> (which is the last command), but managed to rebuild enough
> that the second one thought things were built and it didn't
> need to build again, so it didn't fail.
Yes, I tried them in sequence. After trying to run them in a random manner, I think your explanation is correct.
Thanks Nicola for your very detailed replies. Let me know if you need any extra informations.
(file #15703, file #15704, file #15705, file #15706)
|