Re: Idea: a gui for automatic ./configure && make



Hi
   thanks for comments; I reply once to all comments posted ;)

> On Tue, 2005-12-20 at 12:08 -0800, Jeremy C. Reed wrote:
>> I don't think it is worth it since you'd end up having to recreate a
>> packaging system -- complete with diffs, custom configuration args,
>> installation work-arounds, et cetera as it used more wide-spread.
>>
>
> I second that.
the problem is that many projects does not ship anything else from the raw
source package.
I'm a developer and I work on various OS projects so I know that it's not
easy to provide many packages. Often because it's not so easy to make them
and also because they are platform- and even worse distro- specific !


>> As a packages framework and package developer, I have seen numerous
>> source
>> downloads that install to their own desired locations, overwrite files,
>> destroy configurations, have out-dated or non-standard autoconf
>> ./configure usage, etc.
>>
>
> And as a Linux user, I've seen that compiling a package from source is
> always *not* as simple as a:
>
> $ ./configure && make && sudo make install
yes, it would be wonderful if it always was so pleasant install new
software.
It's not always but I guess a good 70-80% is.


> IMO, if the above set of commands do the job, then why to take the
> *trouble* of compiling from source? A binary package would do that for
> me. :)
what if the binary package doesn't exist ?


> I (and I'm sure most other people) compile from source because I need
> all binaries and libs in one particular location (for easy removal and
> management) or behave in a particular manner. Both of these requirements
> are meant by providing required switches to ./configure. I don't think a
> GUI would help in such cases. :)
the GUI could provide a simple "./configure --help" parser which lets you to
browse the configure options before compiling...

About the fact that source compiling often confuse other package managers, I
cannot say anything: it's true.
Unfortunately most programs do not have any support for these package
managers...

Still I think it's worth to make it a little bit easier for the users
source-compiling.

Autopackages are a great thing. I want to try them out ASAP and maybe create
some autopackage myself.
Unfortunately, *if* (hope so) it will become a "standard" for packaging in
linux world, this will take time.
Meanwhile I have to do the same routine million times ;)


Francesco

question OT: does anyone know if autopackage is going to be supported by
major distro like debian,fedora,suse, etc ?



"B S Srinidhi" <srinidhi-gnome deeproot co in> ha scritto nel messaggio 
news:1135145539 4416 12 camel avirat   
> Hi,
>
> On Tue, 2005-12-20 at 12:08 -0800, Jeremy C. Reed wrote:
>> I don't think it is worth it since you'd end up having to recreate a
>> packaging system -- complete with diffs, custom configuration args,
>> installation work-arounds, et cetera as it used more wide-spread.
>>
>
> I second that.
>
>> As a packages framework and package developer, I have seen numerous 
>> source
>> downloads that install to their own desired locations, overwrite files,
>> destroy configurations, have out-dated or non-standard autoconf
>> ./configure usage, etc.
>>
>
> And as a Linux user, I've seen that compiling a package from source is
> always *not* as simple as a:
>
> $ ./configure && make && sudo make install
>
> IMO, if the above set of commands do the job, then why to take the
> *trouble* of compiling from source? A binary package would do that for
> me. :)
>
> I (and I'm sure most other people) compile from source because I need
> all binaries and libs in one particular location (for easy removal and
> management) or behave in a particular manner. Both of these requirements
> are meant by providing required switches to ./configure. I don't think a
> GUI would help in such cases. :)
>
> Srinidhi. 






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]