Re: advanced bash-ing for long compiles

2016-10-14 Thread Craig Treleaven 
> On Oct 14, 2016, at 7:37 PM, Clemens Lang  wrote:
> - On 15 Oct, 2016, at 01:05, Fred Wright f...@fwright.net wrote:
> ...
>> One can also accomplish this via:
>> 
>>  sudo touch /opt/local/var/macports/build/.metadata_never_index
>> 
>> Though I don't know if this works across all OS versions.
> 
> Do you have documentation on this? The only documentation I could find
> back then suggested that Spotlight will ignore hidden directories, so
> that's why we made it hidden.
> 
Yes, this came up more than 2 years ago.  I couldn’t find official docs at that 
point.  

http://www.mail-archive.com/macports-dev@lists.macosforge.org/msg26538.html

Only a discussion on apple-stackexchange:

http://apple.stackexchange.com/questions/92784/preventing-spotlight-from-indexing-files-folders

Right now, searches on Apple’s Developer site are just endlessly spinning.

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Fred Wright 

On Fri, 14 Oct 2016, Ryan Schmidt wrote:
> On Oct 14, 2016, at 09:50, Ken Cunningham  
> wrote:

> > Oh, one more similar question while I'm at it.
> >
> > I notice mdworker seems to go nuts during these long builds, often
> > appearing to soak up lots of cycles. I assume it's trying to index
> > all the build files, etc
> >
> > is it easy to sleep that function and then re-enable it after the compile 
> > is done?
>
> I configure Spotlight not to index the /opt/local/var/macports/build 
> directory (System Preferences)

By default, this isn't possible via the GUI, due to the macports
directory's being hidden.

On Sat, 15 Oct 2016, Joshua Root wrote:

> Not sure why this would be, since we set the hidden flag on
> ${prefix}/var/macports (technically $portdbpath) which should exclude it
> from Spotlight indexing. Maybe that doesn't work on 10.6? You could try
> adding it to the Privacy list in the Spotlight settings manually.

If you can.  See above.

One can also accomplish this via:

sudo touch /opt/local/var/macports/build/.metadata_never_index

Though I don't know if this works across all OS versions.

Hiding the macports directory also gets in the way of attaching build logs
to tickets, since the browser's dialog box can't navigate to them.  I've
unhid this directory in the past for that reason, but every so often
something "fixes" it.  If preventing indexing is the sole reason for
hiding the directory, wouldn't using ".metadata_never_index" be better?

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Joshua Root 

On 2016-10-15 01:50 , Ken Cunningham wrote:


I notice mdworker seems to go nuts during these long builds, often appearing to 
soak up lots of cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?


Not sure why this would be, since we set the hidden flag on 
${prefix}/var/macports (technically $portdbpath) which should exclude it 
from Spotlight indexing. Maybe that doesn't work on 10.6? You could try 
adding it to the Privacy list in the Spotlight settings manually.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Lawrence Velázquez 
> On Oct 14, 2016, at 10:50 AM, Ken Cunningham 
>  wrote:
> 
> I notice mdworker seems to go nuts during these long builds, often appearing 
> to soak up lots of cycles. I assume it’s trying to index all the build files, 
> etc
> 
> is it easy to sleep that function and then re-enable it after the compile is 
> done?

You should just stop Spotlight from indexing your MacPorts prefix at all
(System Preferences > Spotlight > Privacy).

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Lawrence Velázquez 
> On Oct 14, 2016, at 10:30 AM, Ken Cunningham 
>  wrote:
> 
> long compiles can take hours
> 
> i can ssh into the machine and get it started
> 
> sudo port -v install gcc48 gcc5 gcc6 gcc7
> 
> that, for example, might take several days to finish (if it does
> finish)
> 
> then I control-Z to pause it, and "bg" to throw it into the background
> 
> then I can close my ssh session and the compile proceeds...
> 
> how exactly do I best find that process to "fg" it again? If I just
> log back in and "fg" it, it is not found. but top shows the process is
> humming away in the background, as expected

You can't bring that process back into the foreground because it is no
longer under any shell's job control because you terminated its
controlling shell by exiting the ssh session.

http://mywiki.wooledge.org/BashGuide/JobControl

> is the process different from a local shell vs a remote shell?

There's no real distinction between a "local" shell and a "remote"
shell.

> is this all wrong, and it's way better to use screen or tmux or ???

Yes. Save yourself the headache.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Brandon Allbery 
On Fri, Oct 14, 2016 at 10:30 AM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> how exactly do I best find that process to "fg" it again? If I just log
> back in and "fg" it, it is not found. but top shows the process is humming
> away in the background, as expected
>

You can't; it's not a child of your current shell, so you cannot reattach
it. This is why screen and tmux exist.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread David Bariod 
Hi Ken,

I would really use screen instead and disconnect it and reconnect it later.

David

On Fri, Oct 14, 2016 at 4:30 PM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> Some advice appreciated ...
>
>
> long compiles can take hours
>
> i can ssh into the machine and get it started
>
> sudo port -v install gcc48 gcc5 gcc6 gcc7
>
> that, for example, might take several days to finish (if it does finish)
>
> then I control-Z to pause it, and "bg" to throw it into the background
>
> then I can close my ssh session and the compile proceeds...
>
> how exactly do I best find that process to "fg" it again? If I just log
> back in and "fg" it, it is not found. but top shows the process is humming
> away in the background, as expected
>
> is the process different from a local shell vs a remote shell?
> is this all wrong, and it's way better to use screen or tmux or ???
>
> Thanks,
>
> K
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Ken Cunningham 

> On Oct 14, 2016, at 7:30 AM, Ken Cunningham  
> wrote:
> 
> Some advice appreciated …
> 

Oh, one more similar question while I’m at it.

I notice mdworker seems to go nuts during these long builds, often appearing to 
soak up lots of cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev