bugGNUstep - Bugs: bug #24994, New target for make...

Group
 
 

bug #24994: New target for make...

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Wed 03 Dec 2008 01:44:00 AM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  nico
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 30 Dec 2008 07:01:51 PM UTC, comment #13: 

Fixed by Nicola in a more elegant way.

Fred Kiefer <FredKiefer>
Group Member
Fri 19 Dec 2008 09:56:34 AM UTC, comment #12: 

You could always create a shell alias ...

alias sysinstall='make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM'

Most likely, if you're rebuilding so often, you could use a script.

Thanks

Nicola Pero <nico>
Group Member
Tue 09 Dec 2008 10:17:54 PM UTC, comment #11: 


> but I already forgot to type
> make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install


Adding a new target means ... you forget to type the new target name.

So your solution is to define GNUSTEP_INSTALLATION_DOMAIN in .profile or similar.

Richard Frith-Macdonald <CaS>
Group Member
Tue 09 Dec 2008 09:50:34 PM UTC, comment #10: 

Even if the software should work correctly independent of where it gets installed, I would like to test my GNUstep in a setup that is close enought to what gets installed for most users. And this will be in the SYSTEM domain. I know I can get that, but I already forgot to type

make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

twice and it is annoying to have a wrongly setup system after that.

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Dec 2008 04:00:13 PM UTC, comment #9: 

Somehow the explanation of what domains are for seems to still be misunderstood:

System domain is for your operating system provider to install into.
Local domain is for the administrator of a specific machine to install into
Network domain is for the administrator of a LAN  to install into
User domain is for an individual user to install into

ALL software should work irrespective of the domain it is installed into.



Richard Frith-Macdonald <CaS>
Group Member
Fri 05 Dec 2008 03:36:38 PM UTC, comment #8: 

I welcome the ability to install either in the local or in the system domain, since it will help packagers and users to maintain their systems. I am a bit concerned about the default choices.

My thought is that all stuff provided by gnustep.org should go into System and the rest into Local, but this is purely arbitrary. I imaging wanting certain GAP applications, once completed, to go into System (Login, Installer, NFS mounter for example).

In any case the choice should be quick and easy, for the developer who recompiles often.

make sysinstall

sounds fine to me.

exporting the Domain in your shell config file doesn't sound a good ide ato me, you could remove Local alltogether!

Although, as a personal preference, I'd left the default for make install and woul dhave provided "make localinstall"

After all I'd imagine that the System domain should generally not be writable to the standard user, while Local could be. ALthough the real "local" domain would me the user's home.

Riccardo Mottola <rmottola>
Group Member
Fri 05 Dec 2008 11:48:56 AM UTC, comment #7: 

Well, I want to install stuff in both Local and System when I compile everything by myself and I don't use FHS layout, in order to have a installation that looks like Mac OS X.

In System: GNUstep/Etoile core frameworks, core applications (workspace, window manager, menu server etc.) that should be invisible to the user and eventually developer tools.

In Local: all applications which are expected to be used directly by the user, all additional GNUstep/Etoile frameworks and all third-party frameworks.

I don't really known how OpenStep was installing stuff, but I suppose it was probably similar to Mac OS X scheme even if the paths were a bit different, as it is also the case for GNUstep vs Mac OS X.

If in future, we have an installer for OpenStep-like layout, I expect it to support this installation scheme which takes in account both System and Local as Apple does it with its Installer. With Mac OS X Installer, Apple stuff mostly goes into System, some into Local, but all user-installed stuff goes into Local and User.

Quentin Mathé <qmathe>
Group Member
Wed 03 Dec 2008 12:10:43 PM UTC, comment #6: 


> What is needed is something to install almost everything into Local,
> except GNUstep core and eventually dev-apps into System


I don't understand that ... why do you want to install some stuff in Local and some stuff in System?

If you are a packager, then presumably you want to install everything in System.
If you are not a packager, then you want to install everything in Local.


Richard Frith-Macdonald <CaS>
Group Member
Wed 03 Dec 2008 12:04:17 PM UTC, comment #5: 

export GNUSTEP_INSTALLATION_DOMAIN=SYSTEM will result in everything getting installed into System, right?

What is needed is something to install almost everything into Local, except GNUstep core and eventually dev-apps into System… make sysinstall can play this role for GNUstep core and dev-apps unlike the variable export from what I understand.

Quentin Mathé <qmathe>
Group Member
Wed 03 Dec 2008 09:53:06 AM UTC, comment #4: 

Yes

export GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
...
make install
...
make install
...

should work just fine.  You can even put 'export GNUSTEP_INSTALLATION_DOMAIN=SYSTEM'
in your shell init script if you want everything to always go into System. ;-)

We could add a 'make sysinstall' target though ... hmm.

Thanks

Nicola Pero <nico>
Group Member
Wed 03 Dec 2008 07:47:02 AM UTC, comment #3: 

How about:

GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
make install
...
make install
....
make install


ie, you set the domain once, rather than every time (I assume that would work).

Alternatively, (what I plan to do), you just use 'make install' and forget about setting the domain, since you don't actually need to worry about it as everything should just work whichever domain you use.

I have no particular objection to adding a new make target, but it does seem like a case of adding a little complexity to the code where none is needed.

Richard Frith-Macdonald <CaS>
Group Member
Wed 03 Dec 2008 07:29:37 AM UTC, comment #2: 

I second this request. Yes, the new way of compiling isn't that complicated, but I am very lazy and I recompile GNUstep about twice a day.
I vote for "make sysinstall".

Fred Kiefer <FredKiefer>
Group Member
Wed 03 Dec 2008 01:48:21 AM UTC, comment #1: 

Just to clarify... this is so that "make install" will still go to LOCAL, but that there is another way to install things into SYSTEM that's equally as easy.

GC

Gregory John Casamento <gcasa>
Group administrator
Wed 03 Dec 2008 01:44:00 AM UTC, original submission:  

I would like to see a new target for make which sets the GNUSTEP_INSTALLATION_DOMAIN to SYSTEM.   With the recent changes, it's necessary to type:

make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

I believe this should be shortened in some way.  My suggestion would be:

make system

or

make sysinstall

or something similar to that.  That variable name is extremely long to type.

GC

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by qmathe (Posted a comment)
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-12-30 FredKiefer StatusNone Fixed
        Assigned toNone nico
        Open/ClosedOpen Closed
    2008-12-09 FredKiefer CategoryNone Makefiles
        Item GroupNone Change Request

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code