CEDET

>>> David Engster <deng@...> seems to think that:
>I'd like to use EDE for a small project in Fortran 90, using the 'make'
>project type. I have created ede-source-f90 and ede-gfortran-compiler
>objects, but I'm not sure what to do with those. Should I just put them
>in the ede-proj-target-makefile-objectcode class in ede-proj-obj.el ?
  [ ... ]

Yup, you can add it as a patch to ede-proj-obj.el, or you can do
something like this:

(let ((st (oref ede-proj-target-makefile-objectcode sourcetype)))
  (oset-default ede-proj-target-makefile-objectcode
	        sourcetype
		(cons 'ede-source-f90 st)))


The same goes for the availablecompilers slot.

Once there, when you can create an target for a program or shared
library, and EDE will start offering to add your fortran files to the
target, and can build your Makefile for you.

If you do this as an external support file, that I would love to use
it as an example in the doc which is not very complete in discussing
this topic.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>>I'd like to use EDE for a small project in Fortran 90, using the 'make'
>>project type. I have created ede-source-f90 and ede-gfortran-compiler
>>objects, but I'm not sure what to do with those. Should I just put them
>>in the ede-proj-target-makefile-objectcode class in ede-proj-obj.el ?
>   [ ... ]
>
> Yup, you can add it as a patch to ede-proj-obj.el, or you can do
> something like this:
>
> (let ((st (oref ede-proj-target-makefile-objectcode sourcetype)))
>   (oset-default ede-proj-target-makefile-objectcode
> 	        sourcetype
> 		(cons 'ede-source-f90 st)))

Ah, OK. Maybe this would justify a little helper function to make adding
new object compilers/linkers easier?

> Once there, when you can create an target for a program or shared
> library, and EDE will start offering to add your fortran files to the
> target, and can build your Makefile for you.

I've added the objects, and so far this works; there is still one
problem, though: Fortran 90 also has the concept of "modules", which
makes creating Makefiles much more complicated.

I'll try to keep this short: module files (*.mod) are, roughly spoken,
something like binary includes, i.e. they have to be available at
compile time. They are generated by the compiler during compilation of
the source files containing the definition of the modules. In fact, one
source file can create *two* output files: an object file and a module
file.

While there are pretty sophisticated solutions out there to tackle this
problem, usually involving external utilities, I'd like to keep this
simple by just using another target for module files. This has the
drawback that files may get compiled twice, but I could live with
that. :-)

Module files result from a normal compilation, but the resulting *.mod
files do not get linked. Do I have to create a new target for this, or
is there something readily available that I could use or modify?

Thanks for your help,
David

David Engster <deng@...> writes:
> I'll try to keep this short: module files (*.mod) are, roughly spoken,
> something like binary includes, i.e. they have to be available at
> compile time. They are generated by the compiler during compilation of
> the source files containing the definition of the modules. In fact, one
> source file can create *two* output files: an object file and a module
> file.
[...]
> Module files result from a normal compilation, but the resulting *.mod
> files do not get linked. Do I have to create a new target for this, or
> is there something readily available that I could use or modify?

Hi Eric,

OK, I think I'm almost there. I've created a very simple target

(defclass ede-proj-target-makefile-fmod (ede-proj-target-makefile)
  ((menu :initform nil)
   (keybindings :initform nil)
   (availablecompilers :initform (ede-fmod-compiler))
   (sourcetype :initform (ede-f90-source)))
  "Target for a single module.")

 [... ede-f90-source is defined in ede-proj-obj.el ...]

(defvar ede-fmod-compiler
  (ede-compiler
   "ede-fmod-compiler"
   :name "gfortran"
   :variables '(("F90MOD" . "gfortran"))
   :commands '("$(F90MOD) -c $<")
   :sourcetype '(ede-fmod-source)
   )
  "Compile Fortran modules.")

(defmethod ede-proj-makefile-sourcevar ((this ede-proj-target-makefile-fmod))
  "Return the variable name for THIS's sources."
  (concat (ede-pmake-varname this) "_FMODULES"))

(ede-proj-register-target "fmodule" 'ede-proj-target-makefile-fmod)

Now consider a simple example: one source file which generates the
module, and one source file which depends on that module and generates
the program. With the above target everything works if I *first* create
the "fmodule" target, and after that the "program" target. If I do it
vice versa, it fails, since I have

all: program module

in the Makefile, but I need to have 'module' before 'program'. Is there
some easy way to enforce this, no matter in which order I create the
targets?

Regards,
David

>>> David Engster <deng@...> seems to think that:
>David Engster <deng@...> writes:
>> I'll try to keep this short: module files (*.mod) are, roughly spoken,
>> something like binary includes, i.e. they have to be available at
>> compile time. They are generated by the compiler during compilation of
>> the source files containing the definition of the modules. In fact, one
>> source file can create *two* output files: an object file and a module
>> file.
>[...]
>> Module files result from a normal compilation, but the resulting *.mod
>> files do not get linked. Do I have to create a new target for this, or
>> is there something readily available that I could use or modify?
>
>Hi Eric,
>
>OK, I think I'm almost there. I've created a very simple target
>
>(defclass ede-proj-target-makefile-fmod (ede-proj-target-makefile)
>  ((menu :initform nil)
>   (keybindings :initform nil)
>   (availablecompilers :initform (ede-fmod-compiler))
>   (sourcetype :initform (ede-f90-source)))
>  "Target for a single module.")
>
> [... ede-f90-source is defined in ede-proj-obj.el ...]
>
>(defvar ede-fmod-compiler
>  (ede-compiler
>   "ede-fmod-compiler"
>   :name "gfortran"
>   :variables '(("F90MOD" . "gfortran"))
>   :commands '("$(F90MOD) -c $<")
>   :sourcetype '(ede-fmod-source)
>   )
>  "Compile Fortran modules.")
>
>(defmethod ede-proj-makefile-sourcevar ((this ede-proj-target-makefile-fmod))
>  "Return the variable name for THIS's sources."
>  (concat (ede-pmake-varname this) "_FMODULES"))
>
>(ede-proj-register-target "fmodule" 'ede-proj-target-makefile-fmod)
>
>Now consider a simple example: one source file which generates the
>module, and one source file which depends on that module and generates
>the program. With the above target everything works if I *first* create
>the "fmodule" target, and after that the "program" target. If I do it
>vice versa, it fails, since I have
>
>all: program module
>
>in the Makefile, but I need to have 'module' before 'program'. Is there
>some easy way to enforce this, no matter in which order I create the
>targets?

This is good news.  I solved this once before, and found this in
ede-proj.el in the method project-new-target

    ;; Add it to the project object
    ;;(oset this targets (cons ot (oref this targets)))
    ;; New form: Add to the end using fancy eieio function.
    ;; @todone - Some targets probably want to be in the front.
    ;;           How to do that?
    ;; @ans - See elisp autoloads for answer
    (object-add-to-list this 'targets ot t)

but I can't figure out how I did it in the 5 minute window I have this
morning.

At a guess, you could have the initialize-instance method for one kind
of fortran module automatically create the other target either before,
or after itself.  That way a user only needs to make one kind of
target, and they get ordered properly.  We can also add a
configuration piece to control the 'append' input to
object-add-to-list above.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>>it fails, since I have
>>
>>all: program module
>>
>>in the Makefile, but I need to have 'module' before 'program'. Is there
>>some easy way to enforce this, no matter in which order I create the
>>targets?

[...]

> At a guess, you could have the initialize-instance method for one kind
> of fortran module automatically create the other target either before,
> or after itself.  That way a user only needs to make one kind of
> target, and they get ordered properly. 

But what if I already created a 'program' target, and decide later I
want to put some of the code into a module? Maybe I should create a
completely new 'fortran' target, which doesn't inherit from the
makefile-objectcode class, and which has support for modules?

>  We can also add a configuration piece to control the 'append' input
> to object-add-to-list above.

I think it would be good to have some slot in the target class which
controls that. Maybe just a boolean 'append', or maybe something like
'priority' which holds an integer, and targets would be sorted according
to that?

-David

>>> David Engster <deng@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>>>>> David Engster <deng@...> seems to think that:
>>>it fails, since I have
>>>
>>>all: program module
>>>
>>>in the Makefile, but I need to have 'module' before 'program'. Is there
>>>some easy way to enforce this, no matter in which order I create the
>>>targets?
>
>[...]
>
>> At a guess, you could have the initialize-instance method for one kind
>> of fortran module automatically create the other target either before,
>> or after itself.  That way a user only needs to make one kind of
>> target, and they get ordered properly. 
>
>But what if I already created a 'program' target, and decide later I
>want to put some of the code into a module? Maybe I should create a
>completely new 'fortran' target, which doesn't inherit from the
>makefile-objectcode class, and which has support for modules?
>
>>  We can also add a configuration piece to control the 'append' input
>> to object-add-to-list above.
>
>I think it would be good to have some slot in the target class which
>controls that. Maybe just a boolean 'append', or maybe something like
>'priority' which holds an integer, and targets would be sorted according
>to that?
  [ ... ]

Your last idea is probably the best.  It is unfortunate that the
single compiler notation doesn't work.

Once you have the fortran piece working, we could look at it to see if
the generic "objectcode" version could be adapted to handle a
two-target scenario in an easy way.  I often like prototyping
something specific, then going back later to see how it would work in
a generic fashion.  It takes extra work, but often things turn out a
lot nicer.

Thanks
Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>> At a guess, you could have the initialize-instance method for one kind
>>> of fortran module automatically create the other target either before,
>>> or after itself.  That way a user only needs to make one kind of
>>> target, and they get ordered properly. 
>>
>>But what if I already created a 'program' target, and decide later I
>>want to put some of the code into a module? Maybe I should create a
>>completely new 'fortran' target, which doesn't inherit from the
>>makefile-objectcode class, and which has support for modules?
>>
>>>  We can also add a configuration piece to control the 'append' input
>>> to object-add-to-list above.
>>
>>I think it would be good to have some slot in the target class which
>>controls that. Maybe just a boolean 'append', or maybe something like
>>'priority' which holds an integer, and targets would be sorted according
>>to that?
>   [ ... ]
>
> Your last idea is probably the best.  It is unfortunate that the
> single compiler notation doesn't work.
>
> Once you have the fortran piece working, we could look at it to see if
> the generic "objectcode" version could be adapted to handle a
> two-target scenario in an easy way.

Maybe the best way to solve this 'module' problem is to just use the
'uselinker' slot, since the main difference for these "*.mod" files is
that they do not get linked. So here's what I've done:

* In ede-proj-obj.el I've included definitions for ede-source-f90/f77,
  ede-gfortran-compiler and ede-gfortran-module-compiler. The latter is
  a clone of the former, but with 'uselinker' set to nil (for details
  see the attached defvar's).

* I've included these in ede-proj-target-makefile-objectcode.

* Now I create a new 'Make' project, load my module source code, create
  a new 'program' target called "mymodule" and choose the
  ede-gfortran-module-compiler for that target and set the linker to
  'none'.

* However, compilation fails. EDE still inserts a linker command,
  although the linker is set to 'none' and the 'uselinker' slot from the
  compiler is 'nil'.

To solve this, I'd like to suggest to following patch, which will insert
the linker command only if any of the compilers has 'uselinker' set to t:

--8<---------------cut here---------------start------------->8---
--- ede-pmake.el.~1.56.~	Thu Mar 12 23:38:21 2009
+++ ede-pmake.el	Mon Apr 27 14:33:59 2009
@@ -589,7 +589,11 @@
   "Insert the commands needed by target THIS.
 For targets, insert the commands needed by the chosen compiler."
   (mapc 'ede-proj-makefile-insert-commands (ede-proj-compilers this))
-  (mapc 'ede-proj-makefile-insert-commands (ede-proj-linkers this)))
+  (when (member t
+		(mapcar (lambda (c)
+			  (oref c uselinker))
+			(ede-proj-compilers this)))
+    (mapc 'ede-proj-makefile-insert-commands (ede-proj-linkers this))))
 
 (defmethod ede-proj-makefile-insert-user-rules ((this ede-proj-project))
   "Insert user specified rules needed by THIS target.
--8<---------------cut here---------------end--------------->8---

(BTW, why can a target have more than one compiler/linker?) 

Now, there still remains the problem how the order of the targets can be
determined. Instead of introducing a new slot, maybe there could be a
simple way to change the order of the target through customize? At the
moment, I can call ede-customize-project and choose "targets", but I
cannot change the order there. I think two buttons like "UP" and "DOWN"
next to "[INS] [DEL]" should be enough. The user could then easily bump
targets to the top.

Regards,
David

Here are the above mentioned defvar's:

(defvar ede-source-f90
  (ede-sourcecode "ede-source-f90"
		  :name "Fortran 90/95"
		  :sourcepattern "\\.[fF]9[05]$"
		  :auxsourcepattern "\\.incf$"
		  :garbagepattern '("*.o" ".deps/*.P"))
  "Fortran 90/95 source code definition.")

(defvar ede-source-f77
  (ede-sourcecode "ede-source-f77"
		  :name "Fortran 77"
		  :sourcepattern "\\.\\([fF]\\|for\\)$"
		  :auxsourcepattern "\\.incf$"
		  :garbagepattern '("*.o" ".deps/*.P"))
  "Fortran 77 source code definition.")

(defvar ede-gfortran-compiler
  (ede-object-compiler
   "ede-f90-compiler-gfortran"
   :name "gfortran"
   :dependencyvar '("F90_DEPENDENCIES" . "-Wp,-MD,.deps/$(*F).P")
   :variables '(("F90" . "gfortran")
		("F90_COMPILE" .
		 "$(F90) $(DEFS) $(INCLUDES) $(F90FLAGS)"))
   :rules (list (ede-makefile-rule
		 "f90-inference-rule"
		 :target "%.o"
		 :dependencies "%.f90"
		 :rules '("@echo '$(F90_COMPILE) -c $<'; \\"
			  "$(F90_COMPILE) $(F90_DEPENDENCIES) -o $@ -c $<"
			  )
		 ))
   :sourcetype '(ede-source-f90 ede-source-f77)
   :objectextention ".o"
   :makedepends t
   :uselinker t)
  "Compiler for Fortran 90/95 sourcecode.")

(defvar ede-gfortran-module-compiler
  (clone ede-gfortran-compiler
   "ede-f90-module-compiler-gfortran"
   :name "gfortranmod"
   :sourcetype '(ede-source-f90)
   :commands '("$(F90_COMPILE) -c $^")
   :objectextention ".mod"
   :uselinker nil)
  "Compiler for Fortran 90/95 modules.")


(defvar ede-gfortran-linker
  (ede-linker
   "ede-gfortran-linker"
   :name "gfortran"
   ;; Only use this linker when c++ exists.
   :sourcetype '(ede-source-f90 ede-source-f77)
   :variables  '(("F90_LINK" .
		  "$(F90) $(CFLAGS) $(LDFLAGS) -L. -o $@")
		 )
   :commands '("$(F90_LINK) $^")
   :objectextention "")
  "Linker needed for Fortran programs.")

>>> David Engster <deng@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
  [ ... ]
>> Once you have the fortran piece working, we could look at it to see if
>> the generic "objectcode" version could be adapted to handle a
>> two-target scenario in an easy way.
>
>Maybe the best way to solve this 'module' problem is to just use the
>'uselinker' slot, since the main difference for these "*.mod" files is
>that they do not get linked. So here's what I've done:
>
  [ ... ]
>To solve this, I'd like to suggest to following patch, which will insert
>the linker command only if any of the compilers has 'uselinker' set to t:
>
>--8<---------------cut here---------------start------------->8---
>--- ede-pmake.el.~1.56.~	Thu Mar 12 23:38:21 2009
>+++ ede-pmake.el	Mon Apr 27 14:33:59 2009

Thanks.  I like the idea of using this patch.  I will apply it as soon
as I can.

  [ ... ]

>(BTW, why can a target have more than one compiler/linker?) 

If one fails, it can cascade to the next one.  That way you can have a
canned set of defaults.

  [ ... ]
>
>Now, there still remains the problem how the order of the targets can be
>determined. Instead of introducing a new slot, maybe there could be a
>simple way to change the order of the target through customize? At the
>moment, I can call ede-customize-project and choose "targets", but I
>cannot change the order there. I think two buttons like "UP" and "DOWN"
>next to "[INS] [DEL]" should be enough. The user could then easily bump
>targets to the top.

I don't know if custom supports such a notation.  Perhaps someone one
the list knows more about custom, and how to do that.

Thanks
Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>>Now, there still remains the problem how the order of the targets can be
>>determined. Instead of introducing a new slot, maybe there could be a
>>simple way to change the order of the target through customize? At the
>>moment, I can call ede-customize-project and choose "targets", but I
>>cannot change the order there. I think two buttons like "UP" and "DOWN"
>>next to "[INS] [DEL]" should be enough. The user could then easily bump
>>targets to the top.
>
> I don't know if custom supports such a notation.  Perhaps someone one
> the list knows more about custom, and how to do that.

It seems custom does not support this out of the box, so I hacked some
widgets together to allow sorting the targets of the current project in
a custom-like fashion. I attached the code to this mail; to use it, just
call ede-project-sort-targets while visiting a file belonging to a
project. It could surely be made prettier, but it does the job. :-)

For now, one has to manually regenerate the Makefile after modifying the
target order. Is there some way to mark the project object as "dirty",
so that the Makefile will be automatically regenerated?

-David


(defvar ede-project-sort-targets-order nil)

(defun ede-project-sort-targets ()
  "Creates a custom-like buffer for sorting targets of current project."
  (interactive)
  (let ((proj (ede-current-project))
	(count 1)
	current order)
    (switch-to-buffer (get-buffer-create "*EDE sort targets*"))
    (erase-buffer)
    (setq ede-object-project proj)
    (widget-create 'push-button
		   :notify (lambda (&rest ignore)
			     (let ((targets (oref ede-object-project targets))
				   cur newtargets)
			       (while (setq cur (pop ede-project-sort-targets-order))
				 (setq newtargets (append newtargets 
							  (list (nth cur targets)))))
			       (oset ede-object-project targets newtargets))
			     (kill-buffer))
		   " Accept ")
    (widget-insert "   ")
    (widget-create 'push-button
		   :notify (lambda (&rest ignore)
			       (kill-buffer))
		   " Cancel ")
    (widget-insert "\n\n")
    (setq ede-project-sort-targets-order nil)
    (mapc (lambda (x)
	    (add-to-ordered-list
	     'ede-project-sort-targets-order
	     x x))
	  (number-sequence 0 (1- (length (oref proj targets)))))
    (ede-project-sort-targets-list)
    (use-local-map widget-keymap)
    (widget-setup)
    (goto-char (point-min))))

(defun ede-project-sort-targets-list ()
  (save-excursion
    (let ((count 0)
	  (targets (oref ede-object-project targets))
	  (inhibit-read-only t)
	  (inhibit-modification-hooks t))
      (goto-char (point-min))
      (forward-line 2)
      (delete-region (point) (point-max))
      (while (< count (length targets))
	(if (> count 0)
	    (widget-create 'push-button
			   :notify `(lambda (&rest ignore)
				      (let ((cur ede-project-sort-targets-order))
					(add-to-ordered-list
					 'ede-project-sort-targets-order
					 (nth ,count cur)
					 (1- ,count))
					(add-to-ordered-list
					 'ede-project-sort-targets-order
					 (nth (1- ,count) cur) ,count))
				      (ede-project-sort-targets-list))
			   " Up ")
	  (widget-insert "      "))
	(if (< count (1- (length targets)))
	    (widget-create 'push-button
			   :notify `(lambda (&rest ignore)
				      (let ((cur ede-project-sort-targets-order))
					(add-to-ordered-list
					 'ede-project-sort-targets-order
					 (nth ,count cur) (1+ ,count))
					(add-to-ordered-list
					 'ede-project-sort-targets-order
					 (nth (1+ ,count) cur) ,count))
				      (ede-project-sort-targets-list))
			   " Down ")
	  (widget-insert "        "))
	(widget-insert (concat " " (number-to-string (1+ count)) ".:   "
			       (oref (nth (nth count ede-project-sort-targets-order)
					  targets) name) "\n"))
	(setq count (1+ count))))))

>>> David Engster <deng@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>>>>> David Engster <deng@...> seems to think that:
>>>Now, there still remains the problem how the order of the targets can be
>>>determined. Instead of introducing a new slot, maybe there could be a
>>>simple way to change the order of the target through customize? At the
>>>moment, I can call ede-customize-project and choose "targets", but I
>>>cannot change the order there. I think two buttons like "UP" and "DOWN"
>>>next to "[INS] [DEL]" should be enough. The user could then easily bump
>>>targets to the top.
>>
>> I don't know if custom supports such a notation.  Perhaps someone one
>> the list knows more about custom, and how to do that.
>
>It seems custom does not support this out of the box, so I hacked some
>widgets together to allow sorting the targets of the current project in
>a custom-like fashion. I attached the code to this mail; to use it, just
>call ede-project-sort-targets while visiting a file belonging to a
>project. It could surely be made prettier, but it does the job. :-)

Nice idea.  Have you signed papers with the FSF for contributions to
Emacs?  If not, you can write to copyright-clerk@... and let them
know you are interested in contributions to Emacs/CEDET.

Converting your idea to work in custom directly would be great for all
of Emacs as well.  I can imagine many different kinds of repeat
notations that would benefit.

>For now, one has to manually regenerate the Makefile after modifying the
>target order. Is there some way to mark the project object as "dirty",
>so that the Makefile will be automatically regenerated?
  [ ... ]

After you have changed an EDE object via oset you would want to then
call `ede-commit-project' to tell EDE that you made a change that
needs to be saved.  This will write out a new Project.ede file, and
the timestamp will let it know that the next time you run compile, it
will need to re-write the Makefiles.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

"Eric M. Ludlam" <eric@...> writes:
>>>> David Engster <deng@...> seems to think that:
>>It seems custom does not support this out of the box, so I hacked some
>>widgets together to allow sorting the targets of the current project in
>>a custom-like fashion. I attached the code to this mail; to use it, just
>>call ede-project-sort-targets while visiting a file belonging to a
>>project. It could surely be made prettier, but it does the job. :-)
>
> Nice idea.  Have you signed papers with the FSF for contributions to
> Emacs?

Yes.

> Converting your idea to work in custom directly would be great for all
> of Emacs as well.  I can imagine many different kinds of repeat
> notations that would benefit.

I'll look into that when the feature freeze is over.

>>For now, one has to manually regenerate the Makefile after modifying the
>>target order. Is there some way to mark the project object as "dirty",
>>so that the Makefile will be automatically regenerated?
>   [ ... ]
>
> After you have changed an EDE object via oset you would want to then
> call `ede-commit-project' to tell EDE that you made a change that
> needs to be saved.  This will write out a new Project.ede file, and
> the timestamp will let it know that the next time you run compile, it
> will need to re-write the Makefiles.

Ah, OK. Then the "Accept" button just has to be changed to:

    (widget-create 'push-button
		   :notify (lambda (&rest ignore)
			     (let ((targets (oref ede-object-project targets))
				   cur newtargets)
			       (while (setq cur (pop ede-project-sort-targets-order))
				 (setq newtargets (append newtargets 
							  (list (nth cur targets)))))
			       (oset ede-object-project targets newtargets))
			     (ede-commit-project ede-object-project)
			     (kill-buffer))
		   " Accept ")

-David

>>> David Engster <deng@...> seems to think that:
  [ ... ]
>--8<---------------cut here---------------start------------->8---
>--- ede-pmake.el.~1.56.~	Thu Mar 12 23:38:21 2009
>+++ ede-pmake.el	Mon Apr 27 14:33:59 2009
>@@ -589,7 +589,11 @@
>   "Insert the commands needed by target THIS.
> For targets, insert the commands needed by the chosen compiler."
>   (mapc 'ede-proj-makefile-insert-commands (ede-proj-compilers this))
>-  (mapc 'ede-proj-makefile-insert-commands (ede-proj-linkers this)))
>+  (when (member t
>+		(mapcar (lambda (c)
>+			  (oref c uselinker))
>+			(ede-proj-compilers this)))
>+    (mapc 'ede-proj-makefile-insert-commands (ede-proj-linkers this))))
> 
> (defmethod ede-proj-makefile-insert-user-rules ((this ede-proj-project))
>   "Insert user specified rules needed by THIS target.
>--8<---------------cut here---------------end--------------->8---
  [ ... ]

Hi David,

  I checked in a variant to this patch using object-assoc which is, as
far as I can tell, equivalent to this piece of code.

Enjoy
Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Hi David,

Thanks for the data again.  I've merged in your Fortran patch.  Thanks.

I also added your target sorting mechanism into ede.el, and added a menu
item for it.  I like it.

Thanks
Eric

On Sat, 2009-05-16 at 13:17 +0200, David Engster wrote:

> I have attached a patch with my current Fortran definitions I've put in
> ede-proj-obj.el. Also, I've included my code to sort the targets in a
> 'customize' fashion. I've currently also included this in
> ede-proj-obj.el, but I'm not sure if this is the right place. As I wrote
> in cedet-devel, I'll consider writing a patch for customize.el to
> include this kind of sorting, but I'm currently occupied with other
> things and there's the feature freeze anway. :-)